From dwalsh at redhat.com Thu Dec 1 01:09:27 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 30 Nov 2005 20:09:27 -0500 Subject: custom selinux policy In-Reply-To: <1133384208.19778.50.camel@www.lutty.net> References: <1133215231.19778.28.camel@www.lutty.net> <438C82A9.3060804@redhat.com> <1133292469.19778.41.camel@www.lutty.net> <438CB722.7070100@redhat.com> <1133384208.19778.50.camel@www.lutty.net> Message-ID: <438E4D47.8030302@redhat.com> Laurent Jacquot wrote: > On mar, 2005-11-29 at 15:16 -0500, Daniel J Walsh wrote: > >> Laurent Jacquot wrote: >> >>> On mar, 2005-11-29 at 11:32 -0500, Daniel J Walsh wrote: >>> >>> >>>> Laurent Jacquot wrote: >>>> >>>> >>>>> Hello, >>>>> I can no longer build my custom selinux policy with recent upgrades (SE >>>>> policy source replaced with SE policy). >>>>> What is the new way (used to be make reload)? >>>>> >>>>> tx in advance >>>>> jk >>>>> >>>>> >>>>> >>>>> >>>> You need to use loadable modules. Take a look a the man page for >>>> audit2allow, for some explanation. I don't know if we have a good >>>> description available yet for loadable policy. >>>> >>>> The hardest part of converting your local.te into a loadable module will >>>> be writing the require section. >>>> You need to define all types, class and roles in this section in order >>>> to get the loadable module. >>>> ================================================================================== >>>> module local 1.0; >>>> >>>> require { >>>> role system_r; >>>> >>>> class fifo_file { getattr ioctl }; >>>> >>>> type cupsd_config_t; >>>> type unconfined_t; >>>> }; >>>> >>>> allow cupsd_config_t unconfined_t:fifo_file { getattr ioctl }; >>>> ================================================================================== >>>> >>>> -- >>>> >>>> >>> Thanks a lot for this info. >>> BTW the audit2allow (policycoreutils-1.27.29-1) manpage isn't updated >>> regarding the module stuff. Hopefully, the -M option is verbose >>> >>> Would you mind shed some light on the new file context definition? (used >>> to be local.fc) >>> >>> Laurent >>> >>> >>> >>> >>> >> manpage looks correct on my machine? >> >> File context file should be the same. >> >> checkmodule -M -m -o /tmp/local.mod /tmp/local.te >> semodule_package -o /tmp/local.pp -m /tmp/local.mod -f /tmp/local.fc >> > > Will try as soon as I find time. Does this semanage thing is to be run > each time a reboot occurs in order to load my custom modules or it > recalls it automagically? > Init will automagically load your custum policy > semodule -l Shows all loadable modules currently in put policy. > manpage is ok now that I deleted /var/cache/man/cat1/audit2allow.1.bz2. > Is it a bug? - first time I see this behavior.. > > I have no idea what happened > Anyway, thanks a lot to all the giants managing to transition those > udev, selinux, modular xorg, etc.. so smoothly. > > The wonder of OpenSource. > Laurent > > > -- From johnp at redhat.com Thu Dec 1 01:14:10 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Wed, 30 Nov 2005 20:14:10 -0500 Subject: [Warning] Building new D-Bus packages tomorrow Message-ID: <1133399650.30065.39.camel@remedyz.boston.redhat.com> I'm going to be building 0.60 into rawhide tomorrow. There is some API and ABI changes so the sonames have been incremented. This means any application using D-Bus will have to be recompiled and in some instances code will have to be changed. The API change to look out for is when requesting names the flags have changed and semantics have changed also. There are now three RequestName flags and four results that can be returned. The flags are: #define DBUS_NAME_FLAG_ALLOW_REPLACEMENT 0x1 #define DBUS_NAME_FLAG_REPLACE_EXISTING 0x2 #define DBUS_NAME_FLAG_DO_NOT_QUEUE 0x4 ALLOW_REPLACEMENT states that another service can replace your service as the primary owner of the name. REPLACE_EXISTING states that if there is already a primary owner try to replace it DO_NOT_QUEUE states that if your service can not be the primary owner (i.e. there already is one that does not ALLOW_REPLACEMENT) then have RequestName fail instead of putting your service into the queue The results returned by RequestName are as follows: #define DBUS_REQUEST_NAME_REPLY_PRIMARY_OWNER 1 #define DBUS_REQUEST_NAME_REPLY_IN_QUEUE 2 #define DBUS_REQUEST_NAME_REPLY_EXISTS 3 #define DBUS_REQUEST_NAME_REPLY_ALREADY_OWNER 4 PRIMARY_OWNER indicates you have become the primary owner IN_QUEUE indicates you have been placed in the queue EXISTS indicates you are already in the queue ALREADY_OWNER indicates you are already the primary owner -- John (J5) Palmieri From johnp at redhat.com Thu Dec 1 01:30:01 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Wed, 30 Nov 2005 20:30:01 -0500 Subject: [Warning] Building new D-Bus packages tomorrow In-Reply-To: <1133399650.30065.39.camel@remedyz.boston.redhat.com> References: <1133399650.30065.39.camel@remedyz.boston.redhat.com> Message-ID: <1133400601.30065.45.camel@remedyz.boston.redhat.com> On Wed, 2005-11-30 at 20:14 -0500, John (J5) Palmieri wrote: > #define DBUS_REQUEST_NAME_REPLY_EXISTS 3 > EXISTS indicates you are already in the queue Sorry, this indicates that you specified DO_NOT_QUEUE and a primary owner already exists -- John (J5) Palmieri From mattdm at mattdm.org Thu Dec 1 01:31:14 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Wed, 30 Nov 2005 20:31:14 -0500 Subject: Pipe dreams: yum-based anaconda a step towards on-line yum-based upgrades? In-Reply-To: <1133390112.4117.122.camel@baythorne.infradead.org> References: <20051130202605.GA7078@jadzia.bu.edu> <1133390112.4117.122.camel@baythorne.infradead.org> Message-ID: <20051201013114.GA20846@jadzia.bu.edu> On Wed, Nov 30, 2005 at 10:35:12PM +0000, David Woodhouse wrote: > > But overall, seemed like a pretty successful experiment. And, given the > > super-short lifespan of FC releases, something I'd really be interested in > > having as an option. > I've got plenty of FC4 machines which were upgraded from FC3 or FC2 that > way. It usually takes a little bit of manual assistance (like installing > compat-db and/or compat-openssl packages) but works fine. So, a first cut upgrade-on-the-fly plugin would handle those compat packages, the problem with packages which conflict with old kernels, and things like the "oh, you had mozilla -- now you probably want firefox" hack. And it should know to look for any particular situations where it should bail -- like LVM1. Maybe I should go through the anaconda code and make a Catalog of Kludges. That sounds like a good time. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From katzj at redhat.com Thu Dec 1 02:23:34 2005 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 30 Nov 2005 21:23:34 -0500 Subject: 'everything' install option in FC5test1 In-Reply-To: <20051129130252.GF7549@rednote.net> References: <1132955761.12298.5.camel@mariusa-ro.ro.oracle.com> <1132984226.2860.39.camel@bree.local.net> <20051126143949.GA2261@jadzia.bu.edu> <20051129130252.GF7549@rednote.net> Message-ID: <1133403814.28383.46.camel@bree.local.net> On Tue, 2005-11-29 at 08:02 -0500, Janina Sajka wrote: > Matthew Miller writes: > > On Sat, Nov 26, 2005 at 12:50:26AM -0500, Jeremy Katz wrote: > > > In a lot of cases, packages which aren't listed in the comps file at all > > > (or aren't a dependency of something) perhaps _should_ move to Extras. > > > In addition, I think there probably are packages which should move > > > somewhere into the comps file. File bugs against comps for things that > > > should be listed and aren't. > > > > How about making Anaconda always only do a minimal install, and make > > firstboot have the option to install other things if you want 'em? :) > > Have you forgotten firsboot is inaccessible? You do care about that, > right? Then let's work towards making firstboot accessible. Frankly, that should be done anyway. If you could file specific bugs about things which would help, then we can look into them and work on prioritizing them. We'll want to make sure to take advantage of the basics of ATK at least for testing with dogtail anyway :) Jeremy From katzj at redhat.com Thu Dec 1 02:39:35 2005 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 30 Nov 2005 21:39:35 -0500 Subject: RHGB bug when using fr_CH keyboard. In-Reply-To: <200511291348.jATDmkSU022989@mx3.redhat.com> References: <200511291348.jATDmkSU022989@mx3.redhat.com> Message-ID: <1133404775.28383.49.camel@bree.local.net> On Tue, 2005-11-29 at 13:47 +0100, Michel MENGIS wrote: > Here in swiss we are using fr_CH keyboards. Each time we are installing a > FC4, firstboot runs in FR keyboard layout. So it's difficult to add user at > firstboot. > > Here is a little patch to allow rhgb to run in fr_CH keyboard layout when > /etc/sysconfig/keyboard KEYTABLE key is set to fr_CH or fr_CH-latin1. Can you file this in bugzilla against rhgb so that it doesn't get lost? Thanks! Jeremy From mharris at mharris.ca Thu Dec 1 02:52:36 2005 From: mharris at mharris.ca (Mike A. Harris) Date: Wed, 30 Nov 2005 21:52:36 -0500 Subject: fc5 goals In-Reply-To: <20051129203142.GF17795@devserv.devel.redhat.com> References: <33765.86.199.0.227.1133215376.squirrel@webmail.univ-nantes.fr> <1133216126.24512.78.camel@prometheus.gamehouse.com> <1133217858.11240.8.camel@rousalka.dyndns.org> <438BBB6E.9070505@develer.com> <1133288168.17843.23.camel@rousalka.dyndns.org> <1133293035.753.35.camel@locolhost.localdomain> <1133293827.2804.69.camel@laptopd505.fenrus.org> <20051129200207.GA17929@jadzia.bu.edu> <20051129203142.GF17795@devserv.devel.redhat.com> Message-ID: <438E6574.8040006@mharris.ca> Bill Nottingham wrote: [SNIP] > Label CDs based on A with the standard "Name, Disc 1 ... X". Label > CDs based on B, C, D... with the discid's name, and discs 1 ... X. > > Hence, now anaconda would display: > > To complete the install, you need: > > Fedora Core 5 disc #1 > Fedora Core 5 disc #2 > Fedora Office disc #1 > Fedora Java disc #1 > > I think this sounds like a really good idea Bill. If you were to grab a handful of non-computer-programmer professionals, mom and dad, grandma, Horatio and Abby, etc. I think the above solution would be more obvious and mainstream to them than what we have right now. It's simply a natural modularization of the distribution into sensible product[1] boundaries. I'm a big fan of modularization as of late. ;o) [1] By "product" I do not mean "commercial product". Fedora Core is the natural product of the result of the development effort put into it. The term "product" does not allude to nor require the exchanging of money. The Linux kernel is a product of Linus and friends for example. I clarify this only to avoid obvious anti-corporation sentiment often associated with mentioning the term "product" and it being seen as something for sale for profit by a corporation. From katzj at redhat.com Thu Dec 1 03:09:04 2005 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 30 Nov 2005 22:09:04 -0500 Subject: status of up2date and rhn-applet In-Reply-To: References: <1132852511.3748.7.camel@yoda.loki.me> <50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr> <1132983547.2860.32.camel@bree.local.net> <1133023655l.3593l.6l@serve.riede.org> <20051129075855.GB13739@neu.nirvana> <1133290947.7585.15.camel@cutter> Message-ID: <1133406544.28383.67.camel@bree.local.net> On Wed, 2005-11-30 at 16:44 +0100, Rudolf Kastl wrote: > 30 Nov 2005 11:18:03 +0100, Benny Amorsen : > > >>>>> "sv" == seth vidal writes: > > sv> Well, to be clear ipw2200 is just firmware - the module is in the > > sv> kernel package. > > > > The 1.0.0 module is in the kernel package. No WPA, and horribly buggy. > > ATrpms has 1.0.8. > > i agree... upgrading the ipw2200 module would make it alot more useable. > actually yet i just rolled my own cause for my laptop the currently > shipped version is unacceptable. The way to get modules upgraded is to get them upgraded upstream. Luckily, in this case, 2.6.15-rc .already seems to contain 1.1.3 :) Jeremy From katzj at redhat.com Thu Dec 1 03:10:07 2005 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 30 Nov 2005 22:10:07 -0500 Subject: Pipe dreams: yum-based anaconda a step towards on-line yum-based upgrades? In-Reply-To: <20051130202605.GA7078@jadzia.bu.edu> References: <20051130202605.GA7078@jadzia.bu.edu> Message-ID: <1133406607.28383.70.camel@bree.local.net> On Wed, 2005-11-30 at 15:26 -0500, Matthew Miller wrote: > So, I noticed while doing my first FC5t1 install the upgrades aren't > currently supported in the reworked anaconda. Fair enough; there's a lot of > changes under the hood. But that got me thinking: hey, maybe this is a great > time to get it so that "yum upgrade" can actually easily bring one from one > FC release to the next. (More realistically, maybe FC6 is a great time. But > now might be a time to start thinking about it.) > > I know there's historically been a lot of wacky special-casing in Anaconda, > much of it legacy cruft, and much of it kinda important for, y'know, > actually working upgrades. Unfortunately, a lot of it depends on having the new kernel (or other new part of the system) already running and so is hard or impossible to do on a running system. Think about things like the static dev -> udev transition. [snip] > But overall, seemed like a pretty successful experiment. And, given the > super-short lifespan of FC releases, something I'd really be interested in > having as an option. For some releases, it could work. As a general case based on lots of years of making upgrades work, not a chance in hell. Jeremy From katzj at redhat.com Thu Dec 1 03:10:17 2005 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 30 Nov 2005 22:10:17 -0500 Subject: Pipe dreams: yum-based anaconda a step towards on-line yum-based upgrades? In-Reply-To: <20051130204120.GA9106@jadzia.bu.edu> References: <20051130202605.GA7078@jadzia.bu.edu> <20051130202856.GA7234@devserv.devel.redhat.com> <1133382724.7253.16.camel@cutter> <20051130203501.GB8611@jadzia.bu.edu> <1133383083.7253.18.camel@cutter> <20051130204120.GA9106@jadzia.bu.edu> Message-ID: <1133406617.28383.72.camel@bree.local.net> On Wed, 2005-11-30 at 15:41 -0500, Matthew Miller wrote: > On Wed, Nov 30, 2005 at 03:38:03PM -0500, seth vidal wrote: > > > Right, that's why I'm not at all suggesting "normal" yum ought to take > > > care of it. Crack-riddled hacks are why we have yum plugins, right? :) > > you _really_ don't want to do a lot of those things on a running system. > > REALLY > > Yeah; some things would have to be pushed to being done on a reboot. Fair > enough, for a whole-system upgrade. > > But how many such cases are there really? Enough that it's guaranteed to be problematic. Plus, the infrastructure to defer changes is likely to be fragile and under-tested. Jeremy From katzj at redhat.com Thu Dec 1 03:10:23 2005 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 30 Nov 2005 22:10:23 -0500 Subject: Pipe dreams: yum-based anaconda a step towards on-line yum-based upgrades? In-Reply-To: <1133388025.10697.84.camel@rousalka.dyndns.org> References: <20051130202605.GA7078@jadzia.bu.edu> <20051130202856.GA7234@devserv.devel.redhat.com> <20051130203205.GA8611@jadzia.bu.edu> <20051130203309.GB7234@devserv.devel.redhat.com> <20051130203623.GC8611@jadzia.bu.edu> <1133383114.7253.20.camel@cutter> <1133383754.10697.31.camel@rousalka.dyndns.org> <1133383986.7253.31.camel@cutter> <1133385242.10697.56.camel@rousalka.dyndns.org> <1133386357.2936.23.camel@localhost.localdomain> <1133388025.10697.84.camel@rousalka.dyndns.org> Message-ID: <1133406623.28383.73.camel@bree.local.net> On Wed, 2005-11-30 at 23:00 +0100, Nicolas Mailhot wrote: > And then a full release upgrade would just be > 1. update packages via yum > 2. the new fedora-release file depends on one or several firstboot > packages, which are therefore installed during the yum upgrade > 3. on installation these packages create a "distro upgrade" bootloader > entry, make it default and ask to reboot > 4. user reboots on this entry and the actions which can not be done on a > live system are performed. Except what happens when one of the packages you're updating requires some of the other changes that would have to be done by one your "firstboot packages"? This isn't some sort of philosophical debate -- it's something that comes up at least every other release if not every release. Jeremy From nicolas.mailhot at laposte.net Thu Dec 1 07:21:40 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 01 Dec 2005 08:21:40 +0100 Subject: Pipe dreams: yum-based anaconda a step towards on-line yum-based upgrades? In-Reply-To: <1133406623.28383.73.camel@bree.local.net> References: <20051130202605.GA7078@jadzia.bu.edu> <20051130202856.GA7234@devserv.devel.redhat.com> <20051130203205.GA8611@jadzia.bu.edu> <20051130203309.GB7234@devserv.devel.redhat.com> <20051130203623.GC8611@jadzia.bu.edu> <1133383114.7253.20.camel@cutter> <1133383754.10697.31.camel@rousalka.dyndns.org> <1133383986.7253.31.camel@cutter> <1133385242.10697.56.camel@rousalka.dyndns.org> <1133386357.2936.23.camel@localhost.localdomain> <1133388025.10697.84.camel@rousalka.dyndns.org> <1133406623.28383.73.camel@bree.local.net> Message-ID: <1133421703.14044.7.camel@rousalka.dyndns.org> Le mercredi 30 novembre 2005 ? 22:10 -0500, Jeremy Katz a ?crit : > On Wed, 2005-11-30 at 23:00 +0100, Nicolas Mailhot wrote: > > And then a full release upgrade would just be > > 1. update packages via yum > > 2. the new fedora-release file depends on one or several firstboot > > packages, which are therefore installed during the yum upgrade > > 3. on installation these packages create a "distro upgrade" bootloader > > entry, make it default and ask to reboot > > 4. user reboots on this entry and the actions which can not be done on a > > live system are performed. > > Except what happens when one of the packages you're updating requires > some of the other changes that would have to be done by one your > "firstboot packages"? This isn't some sort of philosophical debate -- > it's something that comes up at least every other release if not every > release. I won't say such a thing does not exist, but continuous yumable rolling rawhide would not be possible in this case, and my experience is you can "forget" to go through anaconda most of the releases. This could probably be solved by doing the package upgrade bit in several passes (Also please note several passes are only needed if some of those needed bits must be done on a cold system - the rest is only normal package install ordering yum does all the time, just make the packages that need firstboot to be run depend on it) -- 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 mharris at mharris.ca Thu Dec 1 07:33:38 2005 From: mharris at mharris.ca (Mike A. Harris) Date: Thu, 01 Dec 2005 02:33:38 -0500 Subject: Modern Update System In-Reply-To: <1133239969.2937.0.camel@entropy> References: <1133225199.24512.113.camel@prometheus.gamehouse.com> <1133232911.5030.16.camel@dhollis-lnx.sunera.com> <20051128192340.602a02b1.zaitcev@redhat.com> <1133235130.5030.26.camel@dhollis-lnx.sunera.com> <438BDBBE.7080005@didntduck.org> <1133239969.2937.0.camel@entropy> Message-ID: <438EA752.3000407@mharris.ca> Nicholas Miell wrote: > On Mon, 2005-11-28 at 23:40 -0500, Brian Gerst wrote: > > >>We don't need to repeat their mistakes. Most RPMs are small enough that >>there is no net gain using this method. >> > > > And from time to time, there's a full 300 MB OpenOffice release for a > one-line fix to the shell script that launches the whole thing. If that's a common thing, then perhaps that script should be split out into it's own src.rpm, perhaps along with some other scripts or whatnot that are frequently updated. That was the general idea behind the "xinitrc" package which we've just obsoleted for FC5. Perhaps the openoffice project upstream would consider modularizing their project like X.Org has done for X? I've no idea, but it's just a thought. The way I see it, there are 2 extremes - "too monolithic" and "too modular". The trick is getting the right level of granularity to give a good balance of tradeoffs, both in the upstream project, as well as at the distribution packaging level. Then tweaking the modularization granularity over time based on the results of using it in practice. 300Mb monolithic updates of anything, really really sucks. ;o) From fedora at leemhuis.info Thu Dec 1 07:57:12 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 01 Dec 2005 08:57:12 +0100 Subject: Modern Update System In-Reply-To: <438EA752.3000407@mharris.ca> References: <1133225199.24512.113.camel@prometheus.gamehouse.com> <1133232911.5030.16.camel@dhollis-lnx.sunera.com> <20051128192340.602a02b1.zaitcev@redhat.com> <1133235130.5030.26.camel@dhollis-lnx.sunera.com> <438BDBBE.7080005@didntduck.org> <1133239969.2937.0.camel@entropy> <438EA752.3000407@mharris.ca> Message-ID: <1133423832.15523.16.camel@thl.ct.heise.de> Am Donnerstag, den 01.12.2005, 02:33 -0500 schrieb Mike A. Harris: > Nicholas Miell wrote: > > On Mon, 2005-11-28 at 23:40 -0500, Brian Gerst wrote: > >>We don't need to repeat their mistakes. Most RPMs are small enough that > >>there is no net gain using this method. > > And from time to time, there's a full 300 MB OpenOffice release for a > > one-line fix to the shell script that launches the whole thing. >[...] > 300Mb monolithic updates of anything, really really sucks. ;o) Small note to correct one myth about the size referred in this discussion: Yes, with all languages and stuff openoffice in FC4 is 310 MByte -- but yum downloaded only 114 MByte for me with the latest update from updates-testing (all openoffice core components + german langpack). So talking about "a full 300 MB OpenOffice release" is in some way correct, but for most users yum will only download far less (something around 115 MByte, depending on size of the language package). (And yes, I know that this is still much.) CU thl From dwmw2 at infradead.org Thu Dec 1 08:11:27 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 01 Dec 2005 08:11:27 +0000 Subject: Pipe dreams: yum-based anaconda a step towards on-line yum-based upgrades? In-Reply-To: <1133385242.10697.56.camel@rousalka.dyndns.org> References: <20051130202605.GA7078@jadzia.bu.edu> <20051130202856.GA7234@devserv.devel.redhat.com> <20051130203205.GA8611@jadzia.bu.edu> <20051130203309.GB7234@devserv.devel.redhat.com> <20051130203623.GC8611@jadzia.bu.edu> <1133383114.7253.20.camel@cutter> <1133383754.10697.31.camel@rousalka.dyndns.org> <1133383986.7253.31.camel@cutter> <1133385242.10697.56.camel@rousalka.dyndns.org> Message-ID: <1133424687.4117.170.camel@baythorne.infradead.org> On Wed, 2005-11-30 at 22:13 +0100, Nicolas Mailhot wrote: > Anaconda requires you to get an installation image somewhere and burn it > to a CD/DVD. No, it doesn't. You can do anaconda-based upgrades remotely without any physical access to the machine, although obviously it's best to do it at a time when someone _could_ get at the machine if it goes wrong. Stick the vmlinuz and ramdisk.image.gz from the installer into your /boot and point yaboot.conf (or grub.conf) at them with enough arguments to get an IP address and start VNC. (I think you also have to specify keyboard type?). Reboot. Connect with VNC. Pause to swear vehemently about the fact that you can't now point it at the copy of the Fedora install tree which is already on your hard drive; that's been broken for the last year or two. Point it at a Fedora mirror somewhere off-site. Upgrade. When it's done, it'll reboot into the new kernel. -- dwmw2 From mls at suse.de Thu Dec 1 10:46:45 2005 From: mls at suse.de (Michael Schroeder) Date: Thu, 1 Dec 2005 11:46:45 +0100 Subject: Modern Update System In-Reply-To: References: <20051129093348.GB5877@suse.de> <20051130090146.GA13266@suse.de> <20051130095822.GA26582@suse.de> <1133360851.4956.2.camel@dhollis-lnx.sunera.com> <20051130143642.GA7077@suse.de> <20051130160931.GA5788@orient.maison.moi> <20051130162923.GB6945@suse.de> Message-ID: <20051201104644.GA25517@suse.de> On Wed, Nov 30, 2005 at 04:51:18PM -0500, Benjy Grogan wrote: > You said Mandriva and Novell were using these two methods. What is > preventing their widespread adoption because they seem to me to be exactly > what is need in Fedora? Don't ask me ;-) > Either way, sounds great. I should probably install Mandriva or SuSE one of > these days and check it out. You can also just compile and install the deltarpm package and test things. It's available from: ftp://ftp.suse.com/pub/projects/deltarpm/deltarpm-3.3.tar.bz2 Cheers, Michael. -- Michael Schroeder mls at suse.de main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);} From fedora-devel-list at cygnusx-1.org Thu Dec 1 10:56:49 2005 From: fedora-devel-list at cygnusx-1.org (Nathan Grennan) Date: Thu, 1 Dec 2005 02:56:49 -0800 (PST) Subject: Marvell 88E8053, sky2, and netdev Message-ID: <54045.66.224.116.99.1133434609.squirrel@www.okcforum.org> I have a MSI K8N Neo4 Platinum motherboard. It includes a Marvell 88E8053 ethernet controller. From what I see online it seems the right driver is the sky2 driver. I see hints that it was in the netdev.2 package, but seems to be missing from the netdev.3 package. Has it been removed from netdev? Is it too unstable? Will it be coming back? Is there an alternative? I would try using the netdev.2 packages, but the rpms are no longer avaliable. I have also tried skge, sk98lin, and skfp. They seem to do nothing. I bought the Platinum over the F model so that I would have dual onboard network cards like my previous MSI K8N Neo2 Platinum motherboard. From pertusus at free.fr Thu Dec 1 10:59:14 2005 From: pertusus at free.fr (Patrice Dumas) Date: Thu, 1 Dec 2005 11:59:14 +0100 Subject: Modern Update System In-Reply-To: <20051201104644.GA25517@suse.de> References: <20051130090146.GA13266@suse.de> <20051130095822.GA26582@suse.de> <1133360851.4956.2.camel@dhollis-lnx.sunera.com> <20051130143642.GA7077@suse.de> <20051130160931.GA5788@orient.maison.moi> <20051130162923.GB6945@suse.de> <20051201104644.GA25517@suse.de> Message-ID: <20051201105914.GE3870@free.fr> > ftp://ftp.suse.com/pub/projects/deltarpm/deltarpm-3.3.tar.bz2 I believe a first step would be inclusion in extras. -- Pat From rob at choralone.org Thu Dec 1 11:13:09 2005 From: rob at choralone.org (Rob Andrews) Date: Thu, 1 Dec 2005 11:13:09 +0000 Subject: Marvell 88E8053, sky2, and netdev In-Reply-To: <54045.66.224.116.99.1133434609.squirrel@www.okcforum.org> References: <54045.66.224.116.99.1133434609.squirrel@www.okcforum.org> Message-ID: <20051201111308.GA19445@testure.choralone.org> On 01-Dec-2005 10:56.49 (GMT), Nathan Grennan wrote: > I have a MSI K8N Neo4 Platinum motherboard. It includes a Marvell > 88E8053 ethernet controller. From what I see online it seems the right > driver is the sky2 driver. I see hints that it was in the netdev.2 > package, but seems to be missing from the netdev.3 package. Has it been > removed from netdev? Is it too unstable? Will it be coming back? Is > there an alternative? It's possible that it *is* covered by the sk98lin driver, but not the in-kernel tree. SysKonnect have a more recent sk98lin available from their site than that in the kernel. It supports the Marvell PCI-E gigabit interface I have, at least (whereas skge & in-kernel sk98lin do not). I do note that sk98lin is not being built in the rawhide kernel package (I don't have an FC4 box to hand so I can't tell if it's being built for that), but skge is. It could be a small matter of adding the PCI IDs to the skge driver to get it working. I'll try it once I have a spare moment. -- rob andrews rob at choralone.org From Axel.Thimm at ATrpms.net Thu Dec 1 11:22:43 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 1 Dec 2005 12:22:43 +0100 Subject: status of up2date and rhn-applet In-Reply-To: <1133302973l.22893l.6l@serve.riede.org> References: <20051129075855.GB13739@neu.nirvana> <1133302973l.22893l.6l@serve.riede.org> Message-ID: <20051201112243.GN13775@neu.nirvana> On Tue, Nov 29, 2005 at 10:22:53PM +0000, Willem Riede wrote: > On 11/29/2005 02:58:55 AM, Axel Thimm wrote: > >On Mon, Nov 28, 2005 at 10:57:48AM +0100, Benny Amorsen wrote: > >> >>>>> "WR" == Willem Riede writes: > >> > >> WR> Maybe I shouldn't care, but I do. As an example, with all due > >> WR> respect to its creator, the atrpms repository holds both packages > >> WR> I want (unique functionality) and that I don't want (core > >> WR> replacements). Unfortunately that means I can never do a blind > >> WR> cross-the-board upgrade from all the sources I've identified. > >> > >> It would be very nice if one of the update utilities could be set to > >> ignore updates across repositories. I.e. if I've installed foo from > >> core and bar from atrpms and atrpms has newer versions of both foo and > >> bar, only bar gets updated. > > > >Maybe it's better to avoid atrpms at all then, as its bar will > >probably assume that you are using foo from the same source? Perhaps > >foo in core is being replaced just to add the functionality that bar > >needs? > > Good point. I would hope that in such cases the bar from add-on repos has > an explicit Requires: on the foo fromthe same repo... how would you do that? rpm only allows specifying a name and a version. Requires: foo-from-repoX is an ugly hack nobody wants to see. > >It isn't as black or white as it seems. I've had enough bug reports on > >using apt and smart with priorities/weights to strongly advise against > >their use (not apt/smart's, but their weighing mechanisms). > > > >And if you don't trust repo X to replace package Y, then why trust it > >to offer package Z? Better drop repo X, if you feel uncomfortable. > > Well, that aspect is also not black and white :-) Some repo may have > several clusters of changed or additional rpms, and I may want one of > those clusters because my desire for that functionality is larger than my > concern for the system's stability, but I am happy with the base > distribution for other clusters, so I don't want those replaced. The issue is indeed that you'd like to see some of the clusters in separate sub-repos. But everyone has a different preference of what these subrepos should be. If a repo maintainer would be to implement this splitting he would be doing nothing else. Consider also sub-repos sharing packages, like fftw for scientific and multimedia repos. It is a living nighmare. I have though about that a lot to get off the discussion on weighted and prefered subsets of packages, but the Gedankenexperiments always ends with catastrophies. > The way I'd love to be able to do it, is to initially explicitely install > new rpms and accept upgrades due to dependencies of the rpm that provides > the new functionality, and later when doing "yum update" have only rpms > that originate from the same repo as what is already installed (on a > package by package basis) selected. Same problem, if you want foo from repoX, and bar remains on repoY's functionality . -- 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 reuben-fedora-devel at reub.net Thu Dec 1 11:23:24 2005 From: reuben-fedora-devel at reub.net (Reuben Farrelly) Date: Fri, 02 Dec 2005 00:23:24 +1300 Subject: Marvell 88E8053, sky2, and netdev In-Reply-To: <20051201111308.GA19445@testure.choralone.org> References: <54045.66.224.116.99.1133434609.squirrel@www.okcforum.org> <20051201111308.GA19445@testure.choralone.org> Message-ID: <438EDD2C.4090000@reub.net> Hi, On 2/12/2005 12:13 a.m., Rob Andrews wrote: > On 01-Dec-2005 10:56.49 (GMT), Nathan Grennan wrote: > > I have a MSI K8N Neo4 Platinum motherboard. It includes a Marvell > > 88E8053 ethernet controller. From what I see online it seems the right > > driver is the sky2 driver. I see hints that it was in the netdev.2 > > package, but seems to be missing from the netdev.3 package. Has it been > > removed from netdev? Is it too unstable? Will it be coming back? Is > > there an alternative? > > It's possible that it *is* covered by the sk98lin driver, but not the > in-kernel tree. SysKonnect have a more recent sk98lin available from > their site than that in the kernel. It supports the Marvell PCI-E > gigabit interface I have, at least (whereas skge & in-kernel sk98lin do > not). > > I do note that sk98lin is not being built in the rawhide kernel package > (I don't have an FC4 box to hand so I can't tell if it's being built for > that), but skge is. It could be a small matter of adding the PCI IDs to > the skge driver to get it working. I'll try it once I have a spare moment. Forget about the sk98lin from SysKonnect, the two new drivers that have been written recently for those cards are orders of magnitudes better than the SysKonnect one. I'm referring to the skge driver, and the new sky2. I know because I have an 88E8050 myself, which is not supported with the skge driver but is supported under sky2. Having spent the last 3 or 4 months trying to get it to work the breakthrough came a week or so ago and ever since it has been flawless. The author of the code (Stephen Hemminger @ OSDL) has since fixed this issue properly in the sky2 driver. The sk98lin driver from Syskonnect also worked around the same issue, by restarting the controller on the card every minute or so if various counters did not increment. That method of 'fixing' probably gives you an idea why I suggested avoiding the SysKonnect one in my opening sentence. A fairly recent sky2 is in -mm (v0.7), but the v0.9 version which fixes all known bugs to date is going to be in 2.6.16 (it's queued in the bk-netdev git repository if people are interested). So if you can wait till 2.6.16 opens up and git-netdev is merged you should be OK, or else grab the 'upstream' branch of git-netdev from Jeff Garziks tree now and try patch 2.6.15-rc4. http://marc.theaimsgroup.com/?l=linux-netdev is also a good place to watch. I would not suggest just adding PCI IDs, Stephen Hemminger is responsive to emails so if that is the right thing to do it should be done via him so that the fix goes upstream. The sk98lin driver in the kernel is gradually being deprecated away and my understanding is that it is likely to receive little if any maintenance going forward. So I don't think the chances of it being re-enabled in rawhide are too good. Reuben From Axel.Thimm at ATrpms.net Thu Dec 1 11:25:54 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 1 Dec 2005 12:25:54 +0100 Subject: status of up2date and rhn-applet In-Reply-To: <1133406544.28383.67.camel@bree.local.net> References: <50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr> <1132983547.2860.32.camel@bree.local.net> <1133023655l.3593l.6l@serve.riede.org> <20051129075855.GB13739@neu.nirvana> <1133290947.7585.15.camel@cutter> <1133406544.28383.67.camel@bree.local.net> Message-ID: <20051201112554.GO13775@neu.nirvana> On Wed, Nov 30, 2005 at 10:09:04PM -0500, Jeremy Katz wrote: > On Wed, 2005-11-30 at 16:44 +0100, Rudolf Kastl wrote: > > 30 Nov 2005 11:18:03 +0100, Benny Amorsen : > > > >>>>> "sv" == seth vidal writes: > > > sv> Well, to be clear ipw2200 is just firmware - the module is in the > > > sv> kernel package. > > > > > > The 1.0.0 module is in the kernel package. No WPA, and horribly buggy. > > > ATrpms has 1.0.8. > > > > i agree... upgrading the ipw2200 module would make it alot more useable. > > actually yet i just rolled my own cause for my laptop the currently > > shipped version is unacceptable. > > The way to get modules upgraded is to get them upgraded upstream. > > Luckily, in this case, 2.6.15-rc .already seems to contain 1.1.3 :) There is no latest than 1.0.8. -- 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 rob at choralone.org Thu Dec 1 11:36:36 2005 From: rob at choralone.org (Rob Andrews) Date: Thu, 1 Dec 2005 11:36:36 +0000 Subject: Marvell 88E8053, sky2, and netdev In-Reply-To: <438EDD2C.4090000@reub.net> References: <54045.66.224.116.99.1133434609.squirrel@www.okcforum.org> <20051201111308.GA19445@testure.choralone.org> <438EDD2C.4090000@reub.net> Message-ID: <20051201113636.GA19929@testure.choralone.org> On 01-Dec-2005 11:23.24 (GMT), Reuben Farrelly wrote: > The sk98lin driver in the kernel is gradually being deprecated away and my > understanding is that it is likely to receive little if any maintenance > going forward. So I don't think the chances of it being re-enabled in > rawhide are too good. I gathered it had been removed from the package because of numerous issues with it. I tend to try poking PCI IDs into some drivers just as a "suck it and see" approach, but I certainly wouldn't suggest it would be stable. -- rob andrews rob at choralone.org From Axel.Thimm at ATrpms.net Thu Dec 1 11:36:22 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 1 Dec 2005 12:36:22 +0100 Subject: status of up2date and rhn-applet In-Reply-To: References: <1132852511.3748.7.camel@yoda.loki.me> <50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr> <1132983547.2860.32.camel@bree.local.net> <1133023655l.3593l.6l@serve.riede.org> <20051129075855.GB13739@neu.nirvana> Message-ID: <20051201113622.GP13775@neu.nirvana> On Tue, Nov 29, 2005 at 07:50:40PM +0100, Benny Amorsen wrote: > >>>>> "AT" == Axel Thimm writes: > > AT> Maybe it's better to avoid atrpms at all then, as its bar will > AT> probably assume that you are using foo from the same source? > AT> Perhaps foo in core is being replaced just to add the > AT> functionality that bar needs? > > Possibly. In my case I need a few kernel modules (ipw2200 for one), > and I certainly don't want all the rest that atrpms tries to replace. > Anyway, package dependencies are supposed to handle the issue you're > describing. If not, the package dependencies are wrong. No, see my other reply. If this were so, then 99.99% of all package dependecies in the base distro are broken as well. > AT> It isn't as black or white as it seems. I've had enough bug > AT> reports on using apt and smart with priorities/weights to strongly > AT> advise against their use (not apt/smart's, but their weighing > AT> mechanisms). > > AT> And if you don't trust repo X to replace package Y, then why trust > AT> it to offer package Z? Better drop repo X, if you feel > AT> uncomfortable. > > I would drop atrpms in an instant if anyone else provided those kernel > modules. However, noone else does. Atrpms is only usable for me with a > hefty exclude= line, and I'm seriously considering switching to > include=. However, that would mean never again being able to check > with yum whether atrpms provides a certain package. I really wonder what makes accepting "package replacements" so hard, when you accept "kernel functionality replacement". If I were to fear about destabilisation of my system, then I would place avoiding kernel modules at number 1. But no, some are upset that libtool gets replaced, but they happily effectivly replace their kernel modules. And are even (obviously) using the testing repo from ATrpms, as the kernel modules you want are in there. Ergo: If you have concerns with ATrpms replacing some packages, then you should have even more concerns with your wish for ATrpms to replace parts of your kernel. Or if you don't have concerns with the latter, then the former ones are certainly safer to use. The "ATrpms replaces packages!!!" is an old, but effective FUD mechanism to scare users off using ATrpms. Yes, there were Clone Wars before they got on the screen. ATrpms exists several years with a large userbase. If this were such a bad thing to do, there would had been known breakages due to this, right? Like any software project ATrpms is not bug free, but bugs are not related to "package replacement". -- 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 leemhuis.info Thu Dec 1 11:41:57 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 01 Dec 2005 12:41:57 +0100 Subject: status of up2date and rhn-applet In-Reply-To: <20051201112554.GO13775@neu.nirvana> References: <50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr> <1132983547.2860.32.camel@bree.local.net> <1133023655l.3593l.6l@serve.riede.org> <20051129075855.GB13739@neu.nirvana> <1133290947.7585.15.camel@cutter> <1133406544.28383.67.camel@bree.local.net> <20051201112554.GO13775@neu.nirvana> Message-ID: <1133437317.15523.35.camel@thl.ct.heise.de> Am Donnerstag, den 01.12.2005, 12:25 +0100 schrieb Axel Thimm: > On Wed, Nov 30, 2005 at 10:09:04PM -0500, Jeremy Katz wrote: > > On Wed, 2005-11-30 at 16:44 +0100, Rudolf Kastl wrote: > > > i agree... upgrading the ipw2200 module would make it alot more useable. > > Luckily, in this case, 2.6.15-rc .already seems to contain 1.1.3 :) > There is no latest than 1.0.8. Axel, you should be able to guess that small error in this conversation yourself. ;-) The 2.6.15-rc contains version 1.1.3 of ipw2100 and version 1.0.8 of ipw2200 For details see: http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;h=77d2a21d4cd00f879abe206480f80ea75441aca7;hb=5666c0947ede0432ba5148570aa66ffb9febff5b;f=drivers/net/wireless/ipw2100.c http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;h=5e7c7e944c9deb8190d271486737041275f85dcf;hb=5666c0947ede0432ba5148570aa66ffb9febff5b;f=drivers/net/wireless/ipw2200.c CU thl From Axel.Thimm at ATrpms.net Thu Dec 1 11:52:34 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 1 Dec 2005 12:52:34 +0100 Subject: status of up2date and rhn-applet In-Reply-To: <1133437317.15523.35.camel@thl.ct.heise.de> References: <1133023655l.3593l.6l@serve.riede.org> <20051129075855.GB13739@neu.nirvana> <1133290947.7585.15.camel@cutter> <1133406544.28383.67.camel@bree.local.net> <20051201112554.GO13775@neu.nirvana> <1133437317.15523.35.camel@thl.ct.heise.de> Message-ID: <20051201115234.GS13775@neu.nirvana> On Thu, Dec 01, 2005 at 12:41:57PM +0100, Thorsten Leemhuis wrote: > Am Donnerstag, den 01.12.2005, 12:25 +0100 schrieb Axel Thimm: > > On Wed, Nov 30, 2005 at 10:09:04PM -0500, Jeremy Katz wrote: > > > On Wed, 2005-11-30 at 16:44 +0100, Rudolf Kastl wrote: > > > > i agree... upgrading the ipw2200 module would make it alot more useable. > > > Luckily, in this case, 2.6.15-rc .already seems to contain 1.1.3 :) > > There is no latest than 1.0.8. > > Axel, you should be able to guess that small error in this conversation > yourself. ;-) The 2.6.15-rc contains > version 1.1.3 of ipw2100 > and > version 1.0.8 of ipw2200 That would imply that I'm actually looking at what I'm packaging. ipw2x00 and ieee80211 release too often, and I'm too old to memorize all versions :) -- 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 leemhuis.info Thu Dec 1 11:52:46 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 01 Dec 2005 12:52:46 +0100 Subject: status of up2date and rhn-applet In-Reply-To: <20051201113622.GP13775@neu.nirvana> References: <1132852511.3748.7.camel@yoda.loki.me> <50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr> <1132983547.2860.32.camel@bree.local.net> <1133023655l.3593l.6l@serve.riede.org> <20051129075855.GB13739@neu.nirvana> <20051201113622.GP13775@neu.nirvana> Message-ID: <1133437966.15523.42.camel@thl.ct.heise.de> Am Donnerstag, den 01.12.2005, 12:36 +0100 schrieb Axel Thimm: > On Tue, Nov 29, 2005 at 07:50:40PM +0100, Benny Amorsen wrote: > > >>>>> "AT" == Axel Thimm writes: >[...] > The "ATrpms replaces packages!!!" is an old, but effective FUD > mechanism to scare users off using ATrpms. Does that mean that you don't replace packages from core anymore? I tried some month ago the last time and several packages from atrpms replaced packages from core then. CU thl From Axel.Thimm at ATrpms.net Thu Dec 1 11:59:31 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 1 Dec 2005 12:59:31 +0100 Subject: status of up2date and rhn-applet In-Reply-To: <1133437966.15523.42.camel@thl.ct.heise.de> References: <1132852511.3748.7.camel@yoda.loki.me> <50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr> <1132983547.2860.32.camel@bree.local.net> <1133023655l.3593l.6l@serve.riede.org> <20051129075855.GB13739@neu.nirvana> <20051201113622.GP13775@neu.nirvana> <1133437966.15523.42.camel@thl.ct.heise.de> Message-ID: <20051201115931.GT13775@neu.nirvana> On Thu, Dec 01, 2005 at 12:52:46PM +0100, Thorsten Leemhuis wrote: > Am Donnerstag, den 01.12.2005, 12:36 +0100 schrieb Axel Thimm: > > On Tue, Nov 29, 2005 at 07:50:40PM +0100, Benny Amorsen wrote: > > > >>>>> "AT" == Axel Thimm writes: > >[...] > > The "ATrpms replaces packages!!!" is an old, but effective FUD > > mechanism to scare users off using ATrpms. > > Does that mean that you don't replace packages from core anymore? I > tried some month ago the last time and several packages from atrpms > replaced packages from core then. Let me rephrase: "The statement made by some repo maintainers in the past that other repos replacing packages is a bad thing and destabilizes your system is a marketing argument to create a USP for themselves when they decided to change their policy and stop replacing packages." But that was clear from the trimmed context. -- 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 benny+usenet at amorsen.dk Thu Dec 1 12:11:37 2005 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: 01 Dec 2005 13:11:37 +0100 Subject: status of up2date and rhn-applet References: <1132852511.3748.7.camel@yoda.loki.me> <50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr> <1132983547.2860.32.camel@bree.local.net> <1133023655l.3593l.6l@serve.riede.org> <20051129075855.GB13739@neu.nirvana> <1133290947.7585.15.camel@cutter> <1133406544.28383.67.camel@bree.local.net> Message-ID: >>>>> "JK" == Jeremy Katz writes: JK> The way to get modules upgraded is to get them upgraded upstream. Absolutely. There is just the inevitable feature delay between the upstream version and the bleeding edge -- and then there are modules like NTFS, which Fedora won't ship (for good reasons) /Benny From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Thu Dec 1 12:27:51 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Thu, 1 Dec 2005 13:27:51 +0100 Subject: Pipe dreams: yum-based anaconda a step towards on-line yum-based upgrades? In-Reply-To: <20051130202605.GA7078@jadzia.bu.edu> References: <20051130202605.GA7078@jadzia.bu.edu> Message-ID: <20051201132751.1e9fabd3@python2> Matthew Miller wrote : [...] > After some time, this failed, because iiimf-libs is gone, with no > replacement or nothing to obsolete it but with a chain of dependencies. > > Quick fix was to just remove that package and try again. This is not an isolated case : Any package removed from Core without another obsoleting it will cause similar breakage. Now... I know this is going to sound hackish and ugly, but why not have an important Core package (say "fedora-release" for instance) obsolete these removed packages up to their last known version? This still leaves the opportunity to re-introduce them at a later date. My only concern is to know if : - x = 1.0 is installed - the fedora-release to be updated obsoletes x <= 1.0 - x = 1.1 is available for the same transaction Will x get uninstalled by the obsoletes or will it get updated? Having it updated would probably be what most users would expect, but that'll happen only if obsoletes are considered after computing all the updates. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.14-1.1637_FC4 Load : 0.54 0.91 0.77 From buildsys at redhat.com Thu Dec 1 13:46:46 2005 From: buildsys at redhat.com (Build System) Date: Thu, 1 Dec 2005 08:46:46 -0500 Subject: rawhide report: 20051201 changes Message-ID: <200512011346.jB1DkkaM024544@porkchop.devel.redhat.com> New package HelixPlayer Open source media player based on the Helix framework New package apmd Advanced Power Management (APM) BIOS utilities for laptops. New package frysk Frysk execution analysis tool New package gpart A program for recovering corrupt partition tables. New package kernel-xen Older kernel (temporary) to enable xen packages for rawhide New package kon2 KON - Kanji ON Linux console New package longrun Utility to change processor speed on Transmeta CPUs. New package mkbootdisk Creates a boot floppy disk for booting a system. New package openCryptoki Implementation of Cryptoki v2.11 for IBM Crypto Hardware New package s390utils Linux/390 specific utilities. New package xorg-x11-drv-apm Xorg X11 apm video driver New package xorg-x11-drv-ark Xorg X11 ark video driver New package xorg-x11-drv-chips Xorg X11 chips video driver New package xorg-x11-drv-cirrus Xorg X11 cirrus video driver New package xorg-x11-drv-cyrix Xorg X11 cyrix video driver New package xorg-x11-drv-glint Xorg X11 glint video driver New package xorg-x11-drv-i128 Xorg X11 i128 video driver New package xorg-x11-drv-i740 Xorg X11 i740 video driver New package xorg-x11-drv-neomagic Xorg X11 neomagic video driver New package xorg-x11-drv-nsc Xorg X11 nsc video driver New package xorg-x11-drv-rendition Xorg X11 rendition video driver New package xorg-x11-drv-tseng Xorg X11 tseng video driver New package xorg-x11-drv-v4l Xorg X11 v4l video driver Updated Packages: cairo-java-1.0.0-10 ------------------- * Wed Oct 12 2005 Igor Foox - 1.0.0-10 - Added dependency on java-1.4.2-gcj-compat for a javadoc generator (bug# 170494). * Wed Oct 05 2005 Igor Foox - 1.0.0-8 - Imported released 1.0.0 sources from upstream. * Thu Sep 22 2005 Igor Foox - 1.0.0-6 - Made cairo-pdf background optional. glib-java-0.2.0-6 ----------------- kdeadmin-7:3.5.0-1 ------------------ * Tue Nov 29 2005 Than Ngo 7:3.5.0-1 - 3.5 final libgconf-java-2.12.0-2 ---------------------- * Wed Oct 05 2005 Igor Foox - 2.12.0-2 - Imported released 2.12.0 source from upstream. - Changed optional installation prefix to /opt/frysk from /opt. - Added dependency for libgtk-java. * Sat Sep 24 2005 Igor Foox - 2.12.0-1 - Imported libgconf-2.12.0 from upstream. * Fri May 20 2005 Ben Konrath - 2.10.1-3 - Fix permissions on src zip. libglade-java-2.12.0-5 ---------------------- * Wed Oct 05 2005 Igor Foox - 2.12.0-5 - Imported released 2.12.0 sources from upstream. - Changed optional installation prefix to /opt/frysk from /opt. - Changed build depenedency on libgtk-java and libgnome-java to -devel. * Sat Sep 24 2005 Igor Foox - 2.12.0-4 - Imported libglade-java 2.12.0 from upstream. * Fri May 20 2005 Ben Konrath - 2.10.1-5 - Fix permissions of src zip. libgnome-java-2.12.0-2 ---------------------- * Wed Oct 05 2005 Igor Foox - 2.12.0-2 - Import released 2.12.0 sources from upstream. - Change optional installation path to /opt/frysk from /opt. - Change build dependency on glib-java and libgtk-java to -devel. * Sat Sep 24 2005 Igor Foox - 2.12.0-1 - Import libgnome-java 2.12.0. * Fri May 20 2005 Ben Konrath - 2.10.1-3 - Fix permission on src zip. libgtk-java-2.8.0-7 ------------------- * Wed Oct 05 2005 Igor Foox - 2.8.0-7 - Changed build dependency on cairo-java and glib-java to -devel. * Wed Oct 05 2005 Igor Foox - 2.8.0-6 - Imported released 2.8.0 sources from upstream. - Changed optional installation prefix to /opt/frysk from /opt. * Fri Sep 23 2005 Igor Foox - 2.8.0-5 - Updated to 2.8.0 upstream libgtk-java. vim-1:6.4.003-1 --------------- * Wed Nov 30 2005 Karsten Hopp 6.4.003-1 - patchlevel 3 - remove withgui switch as we include vim-X11 in all our distributions now (#174271) vnc-4.1.1-22 ------------ * Fri Nov 18 2005 Tim Waugh 4.1.1-22 - Extension module is not available on all architectures. * Fri Nov 18 2005 Tim Waugh 4.1.1-21 - Install extension module into the correct directory. * Fri Nov 18 2005 Tim Waugh 4.1.1-20 - Fix font path correctly (bug #173160). Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel = 0:2.6.14-1.1696_FC5 cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5smp cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel = 0:2.6.14-1.1696_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 From ndbecker2 at gmail.com Thu Dec 1 14:24:14 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 01 Dec 2005 09:24:14 -0500 Subject: yum update conflict today (FC4) Message-ID: Transaction Check Error: file /usr/share/man/man1/gc.1.gz from install of libgc-devel-6.2-0.2.fc4.rf conflicts with file from package graphviz-2.6-1.fc4 From jspaleta at gmail.com Thu Dec 1 14:35:58 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 1 Dec 2005 09:35:58 -0500 Subject: yum update conflict today (FC4) In-Reply-To: References: Message-ID: <604aa7910512010635g46ca81fav14bb6f459acc47ea@mail.gmail.com> On 12/1/05, Neal Becker wrote: > Transaction Check Error: file /usr/share/man/man1/gc.1.gz from install of > libgc-devel-6.2-0.2.fc4.rf conflicts with file from package > graphviz-2.6-1.fc4 Isn't that an rpmforge libgc-devel? Perhaps you should file that with rpmforge's bugzilla. -jef From linux_4ever at yahoo.com Thu Dec 1 14:36:31 2005 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 1 Dec 2005 06:36:31 -0800 (PST) Subject: updatedb borked Message-ID: <20051201143632.22707.qmail@web51511.mail.yahoo.com> Hi, Tried using locate on rawhide machine... [root at dhcp83-80 ~]# locate iso locate: can not open `/var/lib/mlocate/mlocate.db': No such file or directory [root at dhcp83-80 ~]# updatedb updatedb:/etc/updatedb.conf:2: unknown variable `DAILY_UPDATE' [root at dhcp83-80 ~]# rpm -qf /usr/bin/updatedb mlocate-0.11-1 Is this a known problem? -Steve __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ From maxer1 at xmission.com Thu Dec 1 14:39:07 2005 From: maxer1 at xmission.com (RaXeT) Date: Thu, 01 Dec 2005 07:39:07 -0700 Subject: Marvell 88E8053, sky2, and netdev In-Reply-To: <20051201111308.GA19445@testure.choralone.org> References: <54045.66.224.116.99.1133434609.squirrel@www.okcforum.org> <20051201111308.GA19445@testure.choralone.org> Message-ID: <438F0B0B.3090708@xmission.com> Rob Andrews wrote: >On 01-Dec-2005 10:56.49 (GMT), Nathan Grennan wrote: > > I have a MSI K8N Neo4 Platinum motherboard. It includes a Marvell > > 88E8053 ethernet controller. From what I see online it seems the right > > driver is the sky2 driver. I see hints that it was in the netdev.2 > > package, but seems to be missing from the netdev.3 package. Has it been > > removed from netdev? Is it too unstable? Will it be coming back? Is > > there an alternative? > >It's possible that it *is* covered by the sk98lin driver, but not the >in-kernel tree. SysKonnect have a more recent sk98lin available from >their site than that in the kernel. It supports the Marvell PCI-E >gigabit interface I have, at least (whereas skge & in-kernel sk98lin do >not). > >I do note that sk98lin is not being built in the rawhide kernel package >(I don't have an FC4 box to hand so I can't tell if it's being built for >that), but skge is. It could be a small matter of adding the PCI IDs to >the skge driver to get it working. I'll try it once I have a spare moment > > What is the deal with the kernel tree being minus a functioning SysKonnect driver in the PCI-E gigabit series for this Marvell ethernet controller? I haven't seen a working dev kernel driver in two years. In fact, I have to download from this site: http://www.syskonnect.de/syskonnect/support/driver/htm/sk9elin.html a patch to the kernel to get mine to work. This has been the most frustrating portion of kernel dev in recent memory. I can never use the daily _FC5 dev kernels and get the _FC5 driver to recognize the on board card. Apparently SysKonnect isn't willing to write a stable driver for the kernel dev team to sign off on and incorporate. Very annoying. I have even fussed and fumed at the SysKonnect dev team over this to no end. They just don't care. They'll placate you with, "we're trying real hard to get a stable driver. " Yeah right. :) So enjoy downloading and patching your net driver from SysKonnect. I'm a pro! :) Frank Jacobberger From mitr at volny.cz Thu Dec 1 14:43:56 2005 From: mitr at volny.cz (Miloslav Trmac) Date: Thu, 01 Dec 2005 15:43:56 +0100 Subject: updatedb borked In-Reply-To: <20051201143632.22707.qmail@web51511.mail.yahoo.com> References: <20051201143632.22707.qmail@web51511.mail.yahoo.com> Message-ID: <438F0C2C.8030604@volny.cz> Hello, Steve G wrote: > Tried using locate on rawhide machine... > > [root at dhcp83-80 ~]# locate iso > locate: can not open `/var/lib/mlocate/mlocate.db': No such file or directory > [root at dhcp83-80 ~]# updatedb > updatedb:/etc/updatedb.conf:2: unknown variable `DAILY_UPDATE' > [root at dhcp83-80 ~]# rpm -qf /usr/bin/updatedb > mlocate-0.11-1 > > Is this a known problem? (In the future, please ask bugzilla whether it is a known problem, and file it if not.) Yes, this is known, just remove the DAILY_UPDATE variable. I'll write a scriptlet to do that automatically. I'm quite surprised nobody other has complained in the 20 days mlocate is in rawhide ;-) Thanks, Mirek From rdieter at math.unl.edu Thu Dec 1 14:39:30 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 01 Dec 2005 08:39:30 -0600 Subject: yum update conflict today (FC4) In-Reply-To: References: Message-ID: Neal Becker wrote: > Transaction Check Error: file /usr/share/man/man1/gc.1.gz from install of > libgc-devel-6.2-0.2.fc4.rf conflicts with file from package > graphviz-2.6-1.fc4 By that token, graphviz will conflict with Fedora Extras' gc-devel as well. -- Rex From ndbecker2 at gmail.com Thu Dec 1 14:45:12 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 01 Dec 2005 09:45:12 -0500 Subject: Building FireFox 1.5 SRPMs on FC4... References: <1133368298.3357.63.camel@gilboa-home-dev.localhost> Message-ID: Gilboa Davara wrote: > Hello all, > > Just wondering, I assume that FF 1.5 RPMs will be making their way into > rawhide in the next couple of days. > What are the chances of building their SRPMs on FC4? (x86-64 to be > exact) > Should I just give up and build the vanilla source package? > > Gilboa > Nope. Just tried: pmbuild --rebuild firefox-1.5-1.src.rpm Installing firefox-1.5-1.src.rpm error: Failed build dependencies: nspr-devel >= 4.6 is needed by firefox-1.5-1.x86_64 cairo-devel >= 0.5 is needed by firefox-1.5-1.x86_64 [nbecker at nbecker2 ~]$ rpm -q nspr-devel package nspr-devel is not installed [nbecker at nbecker2 ~]$ sudo yum install nspr-devel cairo-devel Setting up Install Process Setting up repositories Reading repository metadata in from local files Parsing package install arguments No Match for argument: nspr-devel Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Downloading header for cairo-devel to pack into transaction set. cairo-devel-0.2.0-1.2.fc4 100% |=========================| 2.6 kB 00:00 ---> Package cairo-devel.x86_64 0:0.2.0-1.2.fc4.rf set to be updated --> Running transaction check --> Processing Dependency: cairo = 0.2.0-1.2.fc4.rf for package: cairo-devel --> Processing Dependency: libpixman-devel for package: cairo-devel --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Downloading header for libpixman-devel to pack into transaction set. libpixman-devel-0.1.2-1.2 100% |=========================| 2.5 kB 00:00 ---> Package libpixman-devel.x86_64 0:0.1.2-1.2.fc4.rf set to be updated --> Running transaction check --> Processing Dependency: libpixman = 0.1.2-1.2.fc4.rf for package: libpixman-devel --> Processing Dependency: cairo = 0.2.0-1.2.fc4.rf for package: cairo-devel --> Finished Dependency Resolution Error: Missing Dependency: cairo = 0.2.0-1.2.fc4.rf is needed by package cairo-devel Error: Missing Dependency: libpixman = 0.1.2-1.2.fc4.rf is needed by package libpixman-devel From linville at redhat.com Thu Dec 1 14:50:12 2005 From: linville at redhat.com (John W. Linville) Date: Thu, 1 Dec 2005 09:50:12 -0500 Subject: Marvell 88E8053, sky2, and netdev In-Reply-To: <54045.66.224.116.99.1133434609.squirrel@www.okcforum.org> References: <54045.66.224.116.99.1133434609.squirrel@www.okcforum.org> Message-ID: <20051201145012.GG26698@redhat.com> On Thu, Dec 01, 2005 at 02:56:49AM -0800, Nathan Grennan wrote: > I have a MSI K8N Neo4 Platinum motherboard. It includes a Marvell > 88E8053 ethernet controller. From what I see online it seems the right > driver is the sky2 driver. I see hints that it was in the netdev.2 > package, but seems to be missing from the netdev.3 package. Has it been > removed from netdev? Is it too unstable? Will it be coming back? Is > there an alternative? Hmmm...not sure how that happened. I'll make sure it is in netdev.4. John -- John W. Linville linville at redhat.com From rdieter at math.unl.edu Thu Dec 1 14:50:23 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 01 Dec 2005 08:50:23 -0600 Subject: yum update conflict today (FC4) In-Reply-To: References: Message-ID: Rex Dieter wrote: > Neal Becker wrote: > >> Transaction Check Error: file /usr/share/man/man1/gc.1.gz from >> install of >> libgc-devel-6.2-0.2.fc4.rf conflicts with file from package >> graphviz-2.6-1.fc4 > > > By that token, graphviz will conflict with Fedora Extras' gc-devel as well. Nevermind, gc-devel (IMO, correctly) places it's manpage in /usr/share/man/man3/ Looks more like a bug in RPMForge's libgc, though I'm not sure of the wisdom of their providing a package that FE already does (with different naming). -- Rex From tarjei.knapstad at gmail.com Thu Dec 1 14:55:09 2005 From: tarjei.knapstad at gmail.com (Tarjei Knapstad) Date: Thu, 1 Dec 2005 15:55:09 +0100 Subject: Upgrades from one major release to the next Message-ID: With the inclusion of fedora extras support in anaconda, has there been any work done to improve upgrading between major releases? Here are my thoughts on the subject in any case... :) Whenever someone asks "Is it possible to update my FC4 installation to FC5?" or the like, the answers are usually one of: 1. You can do it through yum if you're careful to just follow this lengthy guide , but then again you probably shouldn't. 2. Yes, just use the Upgrade option in Anaconda (but you may run into trouble because of stale packages, configs or whatnot) 3. The best option is to just reinstall from scratch (you did make a separate partition for /home, yeah?) The first option is clearly a mine field and would be very hard to support, so I think it should just be disregarded for now. I'd be more interested in improving on the second option. The current installation document only mentions that "Software which you have installed manually on your existing Fedora Core or Red Hat Linux system may behave differently after an upgrade.", which is fine but doesn't really help the user in any way. As far as I can see, the potential problems with an upgrade include: - Some of your packages have been removed (or moved to Extras), and some new ones might have appeared. My experience with a FC3 -> FC4 upgrade (of an everything-install) was that I was left with a lot of stale packages from FC3 and I missed out on the new stuff like Eclipse on my upgraded FC4 install. Would it be viable to add a "Review package differences" screen to Anaconda? It would be nice to be presented with a list of new software that you may or may not choose to install, as well as a list of stale packages that you probably want to get rid of or find alternatives for in Extras or other repositories. - Your configurations may become invalid (both systemwide in /etc and per user dotfiles/directories). Systemwide configurations that are unchanged should probably just be replaced by newer ones _if they are unchanged_, but I think the current procedure just installs them as .rpmnew? Would it be possible to rename the old ones as .rpmold.fc3 if this is the case? Configurations that are changed by the user should of course not be replaced, but I think they should be logged to a separate file in the root account so that it's possible to review these for the user and check that they're still valid. All this would require sha1 sums of configuration files from old rpm's so I guess it's hard to implement. The per-user configuration stuff is harder to deal with. I've had sufficient trouble with this in the past to generally just get rid of most (if not all) of my user configuration stuff, and just keep my documents from /home. No good ideas here really... - 3rd party software (like Maple in my case), and software that you have built and installed yourself (worst case: ./configure; make install) is likely to run into trouble. Maple is mostly "self sufficient" when it comes to library dependencies, other things are probably built agains system libraries and is likely to fail. I don't know of any other solution to this than to warn the user that this might be the case. Is there such a warning in Anaconda? Or only in the installation guide? As for the 3rd option, reinstall from scratch but keep /home, would it be possible to improve on the suggestion for automatic partitioning to also include a separate /home partition? If this was combined with an upgrade option that clearly stated that it will swipe the system, but keep your /home partition, I guess this would be the most comfortable upgrade path for many home users. (I agree you should still backup your data before attempting an upgrade, but why not make it a bit less likely that you'll have to restore that backup :)). I'd be interested to hear if anyone else has opinions here and like I said earlier, if there's any extra effort that has allready gone into alleviating the pain of upgrades I'd be interested to learn about it. -- Tarjei From fedora at camperquake.de Thu Dec 1 14:56:49 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 1 Dec 2005 15:56:49 +0100 Subject: updatedb borked In-Reply-To: <438F0C2C.8030604@volny.cz> References: <20051201143632.22707.qmail@web51511.mail.yahoo.com> <438F0C2C.8030604@volny.cz> Message-ID: <20051201145649.GB14958@ryoko.camperquake.de> On Thu, Dec 01, 2005 at 03:43:56PM +0100, Miloslav Trmac wrote: > I'm quite surprised nobody other has complained in the 20 days mlocate > is in rawhide ;-) Tells you something about how may people actually use locate these days :) To be honest, I do, I noticed, and I did not file a bug. Shame on me. From jspaleta at gmail.com Thu Dec 1 15:00:03 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 1 Dec 2005 10:00:03 -0500 Subject: yum update conflict today (FC4) In-Reply-To: References: Message-ID: <604aa7910512010700t3bc2ce7fq2e493729806fedef@mail.gmail.com> On 12/1/05, Rex Dieter wrote: > By that token, graphviz will conflict with Fedora Extras' gc-devel as well. Uhm did you forget that you wrote this changelog for gc-devel? Or perhaps the real Rex Dieter has been replaced with an evil cyborg mailinglist posting robot? * Thu Oct 02 2003 Rex Dieter 0:6.2-0.fdr.3 - OK, put manpage in man3. gc-devel and graphviz on FC4 from Extras install fine together on my FC4 machine that is not using 3rd party repos. In fact anyone with yum-utils installed can use repoquery -ql to review the file payload for both these packages without installing them.. before bringing it up on the mailinglist. Luckily I don't actually trust anyone, so I've done it for you. graphviz has /usr/share/man/man1/gc.1.gz gc-devel has /usr/share/man/man3/gc.3.gz No conflict inside Fedora Extras. -jef"Move along, nothing to see here"spaleta From dravet at hotmail.com Thu Dec 1 15:03:22 2005 From: dravet at hotmail.com (Jason Dravet) Date: Thu, 01 Dec 2005 09:03:22 -0600 Subject: udev slowness and selinux Message-ID: There has been some discussion on fedora-selinux-list about udev being slowed by selinux. One of the comments about the slowest is the number of nodes in /dev. Decrease the number of nodes in /dev and booting would be faster. I checked my /dev directory and I think I have found some nodes that are redundant. I have 32 ttySXX nodes in /dev. Please correct me if I am wrong but ttyS is usually used for serial ports. On my system I have two serial ports, both of which are disabled in the bios. I removed my modem when I switched to DSL, so shouldn't there be 0 ttyS nodes? There are 64 ttyXX nodes. Aren't these the virtual terminals I use to login locally? If so shouldn't there only be 7 (Ctrl-F1 through Ctrl-F7)? The selinux-list group is looking into the issue, but I thought maybe until a fix is available this is something that could be looked into. I could be wrong and all of these nodes could be needed, but is so what are they used for? Thanks, Jason From linux_4ever at yahoo.com Thu Dec 1 15:07:37 2005 From: linux_4ever at yahoo.com (Steve G) Date: Thu, 1 Dec 2005 07:07:37 -0800 (PST) Subject: updatedb borked In-Reply-To: <438F0C2C.8030604@volny.cz> Message-ID: <20051201150737.89338.qmail@web51507.mail.yahoo.com> >(In the future, please ask bugzilla whether it is a known problem, and >file it if not.) OK. Everyone is different. I looked in bugzilla and saw nothing. Its now bz 174693. -Steve __________________________________ Yahoo! Music Unlimited Access over 1 million songs. Try it free. http://music.yahoo.com/unlimited/ From rdieter at math.unl.edu Thu Dec 1 15:12:14 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 01 Dec 2005 09:12:14 -0600 Subject: yum update conflict today (FC4) In-Reply-To: <604aa7910512010700t3bc2ce7fq2e493729806fedef@mail.gmail.com> References: <604aa7910512010700t3bc2ce7fq2e493729806fedef@mail.gmail.com> Message-ID: <438F12CE.3020402@math.unl.edu> Jeff Spaleta wrote: > On 12/1/05, Rex Dieter wrote: > >>By that token, graphviz will conflict with Fedora Extras' gc-devel as well. > Uhm did you forget that you wrote this changelog for gc-devel? Or > perhaps the real Rex Dieter has been replaced with an evil cyborg > mailinglist posting robot? > > * Thu Oct 02 2003 Rex Dieter 0:6.2-0.fdr.3 > - OK, put manpage in man3. Ssh... don't tell anyone... oops... On the other hand, if I were a robot, I probably wouldn't have forgotten a changelog from 2+ years ago. (-: -- Rex From pbrobinson at gmail.com Thu Dec 1 15:14:31 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 1 Dec 2005 15:14:31 +0000 Subject: Building FireFox 1.5 SRPMs on FC4... In-Reply-To: References: <1133368298.3357.63.camel@gilboa-home-dev.localhost> Message-ID: <5256d0b0512010714g1a77f044yfbb8fbb94ecf20e9@mail.gmail.com> On 12/1/05, Neal Becker wrote: > Gilboa Davara wrote: > > > Hello all, > > > > Just wondering, I assume that FF 1.5 RPMs will be making their way into > > rawhide in the next couple of days. > > What are the chances of building their SRPMs on FC4? (x86-64 to be > > exact) > > Should I just give up and build the vanilla source package? > > > > Gilboa > > > > Nope. Just tried: Read my post from the other day on how to compile it on FC4 P From bernie at develer.com Thu Dec 1 15:13:29 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Thu, 01 Dec 2005 16:13:29 +0100 Subject: updatedb borked In-Reply-To: <20051201145649.GB14958@ryoko.camperquake.de> References: <20051201143632.22707.qmail@web51511.mail.yahoo.com> <438F0C2C.8030604@volny.cz> <20051201145649.GB14958@ryoko.camperquake.de> Message-ID: <438F1319.4040305@develer.com> Ralf Ertzinger wrote: >> I'm quite surprised nobody other has complained in the 20 days mlocate >> is in rawhide ;-) > > Tells you something about how may people actually use locate these days :) I'd much prefer to use spotlight, if only it was available on Linux. Is anybody workking on something equivalent? > To be honest, I do, I noticed, and I did not file a bug. Shame on me. Me too :) -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From jkeating at j2solutions.net Thu Dec 1 15:36:53 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 01 Dec 2005 07:36:53 -0800 Subject: status of up2date and rhn-applet In-Reply-To: <20051201113622.GP13775@neu.nirvana> References: <1132852511.3748.7.camel@yoda.loki.me> <50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr> <1132983547.2860.32.camel@bree.local.net> <1133023655l.3593l.6l@serve.riede.org> <20051129075855.GB13739@neu.nirvana> <20051201113622.GP13775@neu.nirvana> Message-ID: <1133451413.22074.15.camel@yoda.loki.me> On Thu, 2005-12-01 at 12:36 +0100, Axel Thimm wrote: > I really wonder what makes accepting "package replacements" so hard, > when you accept "kernel functionality replacement". If I were to fear > about destabilisation of my system, then I would place avoiding kernel > modules at number 1. > > But no, some are upset that libtool gets replaced, but they happily > effectivly replace their kernel modules. And are even (obviously) > using the testing repo from ATrpms, as the kernel modules you want are > in there. > The real issue here is that the user wants one little thing from AT. They want to try out an experimental test module for a piece of hardware. They don't want to replace many core packages. They get frustrated when they want to install this little thing and they get a rather confusing dep list. Just why do you force your replacement packages on users? What is it about your replacement core packages that are so much better for Core users that anybody who uses any of your rpms must have all those replacements?[1] It seems to me that you're just waving your hand over it and saying "oh they're fine... don't worry about those..." You're saying that if you want to use a experimental module (and possibly remove it right directly) well too bad, you have to have all these packages too, and you have to like it. [1] It has been a while since I used any AT rpms. I don't know if it is still the case that one AT package would mean replacement of a lot of Core packages anymore. I'm just going by other people's emails and your responses. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From Axel.Thimm at ATrpms.net Thu Dec 1 15:54:37 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 1 Dec 2005 16:54:37 +0100 Subject: status of up2date and rhn-applet In-Reply-To: <1133451413.22074.15.camel@yoda.loki.me> References: <1132852511.3748.7.camel@yoda.loki.me> <50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr> <1132983547.2860.32.camel@bree.local.net> <1133023655l.3593l.6l@serve.riede.org> <20051129075855.GB13739@neu.nirvana> <20051201113622.GP13775@neu.nirvana> <1133451413.22074.15.camel@yoda.loki.me> Message-ID: <20051201155437.GC29035@neu.nirvana> On Thu, Dec 01, 2005 at 07:36:53AM -0800, Jesse Keating wrote: > On Thu, 2005-12-01 at 12:36 +0100, Axel Thimm wrote: > > I really wonder what makes accepting "package replacements" so hard, > > when you accept "kernel functionality replacement". If I were to fear > > about destabilisation of my system, then I would place avoiding kernel > > modules at number 1. > > > > But no, some are upset that libtool gets replaced, but they happily > > effectivly replace their kernel modules. And are even (obviously) > > using the testing repo from ATrpms, as the kernel modules you want are > > in there. > > > > The real issue here is that the user wants one little thing from AT. > They want to try out an experimental test module for a piece of > hardware. They don't want to replace many core packages. They get > frustrated when they want to install this little thing and they get a > rather confusing dep list. Same with updates-testing. If you simply activate updates-testing, because there is a nice pacxkage update you have been waiting for, then you either get the whole bunch, or you need to figure out the dependencies yourself. > Just why do you force your replacement packages on users? Nobody forces anyone. The argument that seems to drift away is that if you don't like a subset of a repo and use tools like apt and smart to automatically filter out some packages, other packages will break if depedending on functionality of the filtered out package. So it's either dropping the repo altogether or figuring out the (functional!) dependencies manually. I just don't want get bug reports, because a user filtered out the upgrade of package bar needed for package foo. > What is it about your replacement core packages that are so much > better for Core users that anybody who uses any of your rpms must > have all those replacements?[1] It depends on the package. Some dependencies require activating more build configure options & BuildRequires, others a newer version. There is no general rule of thumb, and I certainly don't try to kill my time by unneccessary work. > It seems to me that you're just waving your hand over it and saying > "oh they're fine... don't worry about those..." You're saying that > if you want to use a experimental module (and possibly remove it > right directly) well too bad, you have to have all these packages > too, and you have to like it. Is that what updates-testing is saying? Show me the solution there and I'll take it over for atrpms-testing. If you want to only test the latest testing kernel but not gcc/whathever you will face the same situation, either upgrade to all in updates testing, or pull down only the package(s) you need and possibly some further dependencies found there. Do the same with ATrpms and any other repo, you want. You wouldn't use apt's and smart's automated weighing alghorithms on updates-testing for the very same reasons I recommend not to use them on anything else. > [1] It has been a while since I used any AT rpms. I don't know if > it is still the case that one AT package would mean replacement of a > lot of Core packages anymore. I'm just going by other people's > emails and your responses. Well, w/o even testing the repo and its contents how can you make a statement on whether and which packages are unneccessary updates, and whether or not stability of your system is at stake? -- 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 Thu Dec 1 15:58:28 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 1 Dec 2005 10:58:28 -0500 Subject: Pipe dreams: yum-based anaconda a step towards on-line yum-based upgrades? In-Reply-To: <1133406607.28383.70.camel@bree.local.net> References: <20051130202605.GA7078@jadzia.bu.edu> <1133406607.28383.70.camel@bree.local.net> Message-ID: <20051201155828.GA16681@jadzia.bu.edu> On Wed, Nov 30, 2005 at 10:10:07PM -0500, Jeremy Katz wrote: > Unfortunately, a lot of it depends on having the new kernel (or other > new part of the system) already running and so is hard or impossible to > do on a running system. Think about things like the static dev -> udev > transition. Yeah... that's kinda a big wrench in this plan. > [snip] > > But overall, seemed like a pretty successful experiment. And, given the > > super-short lifespan of FC releases, something I'd really be interested in > > having as an option. > For some releases, it could work. As a general case based on lots of > years of making upgrades work, not a chance in hell. If you really think there'll be something like that almost every release, I guess it's not worth pursuing. Oh well. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Thu Dec 1 16:00:40 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Thu, 1 Dec 2005 11:00:40 -0500 Subject: Pipe dreams: yum-based anaconda a step towards on-line yum-based upgrades? In-Reply-To: <20051201132751.1e9fabd3@python2> References: <20051130202605.GA7078@jadzia.bu.edu> <20051201132751.1e9fabd3@python2> Message-ID: <20051201160040.GB16681@jadzia.bu.edu> On Thu, Dec 01, 2005 at 01:27:51PM +0100, Matthias Saou wrote: > > After some time, this failed, because iiimf-libs is gone, with no > > replacement or nothing to obsolete it but with a chain of dependencies. > > Quick fix was to just remove that package and try again. > This is not an isolated case : Any package removed from Core without > another obsoleting it will cause similar breakage. Yeah -- and that's a problem for anaconda too, not exclusive to online updates. > Now... I know this is going to sound hackish and ugly, but why not have an > important Core package (say "fedora-release" for instance) obsolete these > removed packages up to their last known version? This still leaves the > opportunity to re-introduce them at a later date. How about a new "fedora-obsolete-packages", listing everything left in this situation and hey, even giving pointers to reasons why.... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jkeating at j2solutions.net Thu Dec 1 16:37:23 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 01 Dec 2005 08:37:23 -0800 Subject: status of up2date and rhn-applet In-Reply-To: <20051201155437.GC29035@neu.nirvana> References: <1132852511.3748.7.camel@yoda.loki.me> <50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr> <1132983547.2860.32.camel@bree.local.net> <1133023655l.3593l.6l@serve.riede.org> <20051129075855.GB13739@neu.nirvana> <20051201113622.GP13775@neu.nirvana> <1133451413.22074.15.camel@yoda.loki.me> <20051201155437.GC29035@neu.nirvana> Message-ID: <1133455044.22074.46.camel@yoda.loki.me> On Thu, 2005-12-01 at 16:54 +0100, Axel Thimm wrote: > > Well, w/o even testing the repo and its contents how can you make a > statement on whether and which packages are unneccessary updates, and > whether or not stability of your system is at stake? So it seems things have changed since I last tried ATrpms in the FC3 days. Back then, every rpm seemed to dep on an atrpms package, which in turn depd on a lot of core replacements. This doesn't seem to be the case anymore. This is why I made the disclaimer that I hadn't tried atrpms in a while. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From emmanuel.seyman at club-internet.fr Thu Dec 1 16:48:45 2005 From: emmanuel.seyman at club-internet.fr (Emmanuel Seyman) Date: Thu, 1 Dec 2005 17:48:45 +0100 Subject: status of up2date and rhn-applet In-Reply-To: <1133455044.22074.46.camel@yoda.loki.me> References: <50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr> <1132983547.2860.32.camel@bree.local.net> <1133023655l.3593l.6l@serve.riede.org> <20051129075855.GB13739@neu.nirvana> <20051201113622.GP13775@neu.nirvana> <1133451413.22074.15.camel@yoda.loki.me> <20051201155437.GC29035@neu.nirvana> <1133455044.22074.46.camel@yoda.loki.me> Message-ID: <20051201164845.GA30765@orient.maison.moi> On Thu, Dec 01, 2005 at 08:37:23AM -0800, Jesse Keating wrote: > > So it seems things have changed since I last tried ATrpms in the FC3 > days. Back then, every rpm seemed to dep on an atrpms package, which in > turn depd on a lot of core replacements. This doesn't seem to be the > case anymore. This is why I made the disclaimer that I hadn't tried > atrpms in a while. FWIW, installing ATrpms' perl-Template-Toolkit package prompts you to install a package called atrpms to satisfy its dependencies. Emmanuel From ianburrell at gmail.com Thu Dec 1 18:48:10 2005 From: ianburrell at gmail.com (Ian Burrell) Date: Thu, 1 Dec 2005 10:48:10 -0800 Subject: Pipe dreams: yum-based anaconda a step towards on-line yum-based upgrades? In-Reply-To: <1133385242.10697.56.camel@rousalka.dyndns.org> References: <20051130202605.GA7078@jadzia.bu.edu> <20051130202856.GA7234@devserv.devel.redhat.com> <20051130203205.GA8611@jadzia.bu.edu> <20051130203309.GB7234@devserv.devel.redhat.com> <20051130203623.GC8611@jadzia.bu.edu> <1133383114.7253.20.camel@cutter> <1133383754.10697.31.camel@rousalka.dyndns.org> <1133383986.7253.31.camel@cutter> <1133385242.10697.56.camel@rousalka.dyndns.org> Message-ID: On 11/30/05, Nicolas Mailhot wrote: > > Nah > Anaconda requires you to get an installation image somewhere and burn it > to a CD/DVD. A firstboot package would just add an entry to the usual > boot menu, and work even on a CD-less system. Plus a firstboot could be > split into "manage partitions" "manage lvms" ... tools, while anaconda > only knows about update process. > Anaconda does not require burning a CD. Booting from the images/pxeboot/vmlinuz and initrd.img added to grub.conf works well with the installer and packages coming from the hard drive or over the network. I have used that technique a few times to upgrade existing installs. - Ian From dragoran at feuerpokemon.de Thu Dec 1 19:37:12 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Thu, 01 Dec 2005 20:37:12 +0100 Subject: updatedb borked In-Reply-To: <438F1319.4040305@develer.com> References: <20051201143632.22707.qmail@web51511.mail.yahoo.com> <438F0C2C.8030604@volny.cz> <20051201145649.GB14958@ryoko.camperquake.de> <438F1319.4040305@develer.com> Message-ID: <438F50E8.2010607@feuerpokemon.de> Bernardo Innocenti wrote: >Ralf Ertzinger wrote: > > > >>>I'm quite surprised nobody other has complained in the 20 days mlocate >>>is in rawhide ;-) >>> >>> >>Tells you something about how may people actually use locate these days :) >> >> > >I'd much prefer to use spotlight, if only it was available on Linux. >Is anybody workking on something equivalent? > > > > > > there is beagle but it uses mono which can't be included in fc because of legal issues (don't now why should be the same as java) From mpeters at mac.com Thu Dec 1 19:48:44 2005 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 01 Dec 2005 11:48:44 -0800 Subject: updatedb borked In-Reply-To: <438F50E8.2010607@feuerpokemon.de> References: <20051201143632.22707.qmail@web51511.mail.yahoo.com> <438F0C2C.8030604@volny.cz> <20051201145649.GB14958@ryoko.camperquake.de> <438F1319.4040305@develer.com> <438F50E8.2010607@feuerpokemon.de> Message-ID: <1133466524.2696.31.camel@locolhost.localdomain> On Thu, 2005-12-01 at 20:37 +0100, dragoran wrote: > > > there is beagle but it uses mono which can't be included in fc because > of legal issues (don't now why should be the same as java) > My understanding is that it may use some patents that MS owns. From ndbecker2 at gmail.com Thu Dec 1 19:43:47 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 01 Dec 2005 14:43:47 -0500 Subject: Building FireFox 1.5 SRPMs on FC4... References: <1133368298.3357.63.camel@gilboa-home-dev.localhost> <5256d0b0512010714g1a77f044yfbb8fbb94ecf20e9@mail.gmail.com> Message-ID: Peter Robinson wrote: > On 12/1/05, Neal Becker wrote: >> Gilboa Davara wrote: >> >> > Hello all, >> > >> > Just wondering, I assume that FF 1.5 RPMs will be making their way into >> > rawhide in the next couple of days. >> > What are the chances of building their SRPMs on FC4? (x86-64 to be >> > exact) >> > Should I just give up and build the vanilla source package? >> > >> > Gilboa >> > >> >> Nope. Just tried: > > Read my post from the other day on how to compile it on FC4 > > P > Thanks, built. Install complained, though, should I worry? sudo rpm -U RPM/RPMS/x86_64/firefox-1.5-1.x86_64.rpm File '/usr/share/applications/kde/amarok.desktop' contains invalid MIME type 'audio/x-pn-realaudioaudio/x-scpls' that has more than one slash File '/usr/share/applications/kde/amarok.desktop' contains invalid MIME type 'audio/x-pn-realaudioaudio/x-scpls' that has more than one slash From gajownik at fedora.pl Thu Dec 1 20:00:39 2005 From: gajownik at fedora.pl (Dawid Gajownik) Date: Thu, 01 Dec 2005 21:00:39 +0100 Subject: updatedb borked In-Reply-To: <438F50E8.2010607@feuerpokemon.de> References: <20051201143632.22707.qmail@web51511.mail.yahoo.com> <438F0C2C.8030604@volny.cz> <20051201145649.GB14958@ryoko.camperquake.de> <438F1319.4040305@develer.com> <438F50E8.2010607@feuerpokemon.de> Message-ID: <438F5667.9050206@fedora.pl> Dnia 12/01/2005 08:37 PM, U?ytkownik dragoran napisa?: > there is beagle but it uses mono which can't be included in fc because > of legal issues (don't now why should be the same as java) I think that these two links give some insight into this issue: http://osnews.com/permalink.php?news_id=12761&comment_id=64228 http://osnews.com/permalink.php?news_id=12761&comment_id=64240 -- ^_* From dominik at greysector.net Thu Dec 1 20:24:56 2005 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 1 Dec 2005 21:24:56 +0100 Subject: Building FireFox 1.5 SRPMs on FC4... In-Reply-To: References: <1133368298.3357.63.camel@gilboa-home-dev.localhost> <5256d0b0512010714g1a77f044yfbb8fbb94ecf20e9@mail.gmail.com> Message-ID: <20051201202456.GA5125@rathann.pekin.waw.pl> On Thursday, 01 December 2005 at 20:43, Neal Becker wrote: [...] > Thanks, built. Install complained, though, should I worry? > > sudo rpm -U RPM/RPMS/x86_64/firefox-1.5-1.x86_64.rpm > File '/usr/share/applications/kde/amarok.desktop' contains invalid MIME type > 'audio/x-pn-realaudioaudio/x-scpls' that has more than one slash > File '/usr/share/applications/kde/amarok.desktop' contains invalid MIME type > 'audio/x-pn-realaudioaudio/x-scpls' that has more than one slash ^ Insert one ';' here. And file a bugzilla. ;) R. -- APT/YUM RPM repository for Fedora Core http://rpm.greysector.net/ mpg321, xmp, faad2, lame, mad, *mplayer*, rdesktop, tin, xvid, mks, mutt "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From ndbecker2 at gmail.com Thu Dec 1 20:27:12 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 01 Dec 2005 15:27:12 -0500 Subject: Building FireFox 1.5 SRPMs on FC4... References: <1133368298.3357.63.camel@gilboa-home-dev.localhost> <5256d0b0512010714g1a77f044yfbb8fbb94ecf20e9@mail.gmail.com> Message-ID: BTW, any good reason the SRPM is set to build with -Os instead of a more typical setting, like -O2? From gilboada at netvision.net.il Thu Dec 1 22:24:55 2005 From: gilboada at netvision.net.il (Gilboa Davara) Date: Fri, 02 Dec 2005 00:24:55 +0200 Subject: Building FireFox 1.5 SRPMs on FC4... In-Reply-To: <5256d0b0511300950i27e13774h846da1c8513f9bb0@mail.gmail.com> References: <1133368298.3357.63.camel@gilboa-home-dev.localhost> <438DE4EF.9040109@redhat.com> <5256d0b0511300950i27e13774h846da1c8513f9bb0@mail.gmail.com> Message-ID: <1133475895.8045.3.camel@gilboa-home-dev.localhost> On Wed, 2005-11-30 at 17:50 +0000, Peter Robinson wrote: > On 11/30/05, Christopher Aillon wrote: > Almost but not quite. Off the top of my head once you've installed the > spec file you need to: > > In the spec file you need to change the nspr/nspr-devel to > mozilla-nspr[-devel] with version of 1.7.10 (it will inc greater vers) > and remove the cairo dep. > > Then in the firefox-mozconfig remove the lines with system cairo and > pango. You need to remove the pango because it deps on cairo. > > Once you've done that you should be able to do a rpmbuild -ba > firefox.spec and then just wait. I've been doing this ever since the > alphas started to appear in rawhide. > > Pete > Thanks! FF 1.5 (x86-64) is working just fine now. Gilboa From Axel.Thimm at ATrpms.net Thu Dec 1 22:38:39 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 1 Dec 2005 23:38:39 +0100 Subject: status of up2date and rhn-applet In-Reply-To: <1133455044.22074.46.camel@yoda.loki.me> References: <50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr> <1132983547.2860.32.camel@bree.local.net> <1133023655l.3593l.6l@serve.riede.org> <20051129075855.GB13739@neu.nirvana> <20051201113622.GP13775@neu.nirvana> <1133451413.22074.15.camel@yoda.loki.me> <20051201155437.GC29035@neu.nirvana> <1133455044.22074.46.camel@yoda.loki.me> Message-ID: <20051201223839.GB8583@neu.nirvana> On Thu, Dec 01, 2005 at 08:37:23AM -0800, Jesse Keating wrote: > On Thu, 2005-12-01 at 16:54 +0100, Axel Thimm wrote: > > Well, w/o even testing the repo and its contents how can you make a > > statement on whether and which packages are unneccessary updates, and > > whether or not stability of your system is at stake? > > So it seems things have changed since I last tried ATrpms in the FC3 > days. Back then, every rpm seemed to dep on an atrpms package, which in > turn depd on a lot of core replacements. No, that was never the case. Neither did _all_ packages depend on "atrpms", nor did "atrpms" depend on anything else. The truth behind this is that o some packages depended on common helper programs, like - kernel modules for modifying the path of modules.conf for 2.4. kernels and doing some other depmod auxilary stuff. - perl modules for fixing perl's path ordering (getting site in front of vendor/perl) o Removing "atrpms" would result in these packages being removed, as these were inverse dependecies. But "atrpms" never had any dependencies of its own. > This doesn't seem to be the case anymore. This is why I made the > disclaimer that I hadn't tried atrpms in a while. What has changed is that the dependencies above are not needed with modern Fedora Core. perl has been fixed, ATrpms places perl modules under vendor for backwards compatibility with broken perl paths and the kmdl paths are injected through modutils, which has also been fixed in recent Fedora Core, so even that is not neccessary. Speaking of neccessary package replacements (in prior FCs): modutils/module-init-tools had to be patched to look under /updates/ to allow kmdls to properly work. So blindly discarding core updates because "it's bad", or asking to move these packages into a sub-repo, effectively disables almost all of ATrpms. That's just an example. Every package replacement has its own history of neccessity. -- 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 bbbush.yuan at gmail.com Fri Dec 2 01:30:07 2005 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Fri, 2 Dec 2005 09:30:07 +0800 Subject: Upgrades from one major release to the next In-Reply-To: References: Message-ID: <76e72f800512011730q322c9467w@mail.gmail.com> 2005/12/1, Tarjei Knapstad : > > - Your configurations may become invalid (both systemwide in /etc and > per user dotfiles/directories). > > Systemwide configurations that are unchanged should probably just be > replaced by newer ones _if they are unchanged_, but I think the > current procedure just installs them as .rpmnew? Would it be possible > to rename the old ones as .rpmold.fc3 if this is the case? > Configurations that are changed by the user should of course not be > replaced, but I think they should be logged to a separate file in the > root account so that it's possible to review these for the user and > check that they're still valid. All this would require sha1 sums of > configuration files from old rpm's so I guess it's hard to implement. > > The per-user configuration stuff is harder to deal with. I've had > sufficient trouble with this in the past to generally just get rid of > most (if not all) of my user configuration stuff, and just keep my > documents from /home. No good ideas here really... > If yum/rpm would send a detailed mail to all users indicate that what configurations are saved to .rpmold, .rpmnew, etc. and what are replaced then I could believe in yum/rpm more. Currently only packages list are mailed to root account, so I have to run yum in gnome-terminal and double or triple the screen cache in order to find these information. I believe that package management should not be interactive like debian, but still need to present these information to users. -- bbbush ^_^ From jkeating at j2solutions.net Fri Dec 2 01:53:38 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 01 Dec 2005 17:53:38 -0800 Subject: Upgrades from one major release to the next In-Reply-To: <76e72f800512011730q322c9467w@mail.gmail.com> References: <76e72f800512011730q322c9467w@mail.gmail.com> Message-ID: <1133488418.4054.33.camel@yoda.loki.me> On Fri, 2005-12-02 at 09:30 +0800, Yuan Yijun wrote: > If yum/rpm would send a detailed mail to all users indicate that what > configurations are saved to .rpmold, .rpmnew, etc. and what are > replaced then I could believe in yum/rpm more. Currently only packages > list are mailed to root account, so I have to run yum in > gnome-terminal and double or triple the screen cache in order to find > these information. I believe that package management should not be > interactive like debian, but still need to present these information > to users. IIRC the messages you see about .rpmsave and .rpmnew are issued by rpm, not by yum. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From jspaleta at gmail.com Fri Dec 2 01:58:28 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 1 Dec 2005 20:58:28 -0500 Subject: Upgrades from one major release to the next In-Reply-To: <1133488418.4054.33.camel@yoda.loki.me> References: <76e72f800512011730q322c9467w@mail.gmail.com> <1133488418.4054.33.camel@yoda.loki.me> Message-ID: <604aa7910512011758u302bd191ra14e69a6e88e361d@mail.gmail.com> On 12/1/05, Jesse Keating wrote: > IIRC the messages you see about .rpmsave and .rpmnew are issued by rpm, > not by yum. Indeed.... i wish there was a way to log those messages in a centralized way for review without having to screenscrape the stdout scroll looking for them. I don't even think graphical up2date had/has a way to review those messages. I think you could only see them if you ran up2date from a terminal..back in the day. -jef From vonbrand at inf.utfsm.cl Fri Dec 2 01:25:46 2005 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Thu, 01 Dec 2005 22:25:46 -0300 Subject: Pipe dreams: yum-based anaconda a step towards on-line yum-based upgrades? In-Reply-To: Your message of "Thu, 01 Dec 2005 08:21:40 BST." <1133421703.14044.7.camel@rousalka.dyndns.org> Message-ID: <200512020125.jB21PkxZ004566@pincoya.inf.utfsm.cl> Nicolas Mailhot wrote: > Le mercredi 30 novembre 2005 ?? 22:10 -0500, Jeremy Katz a ??crit : > > On Wed, 2005-11-30 at 23:00 +0100, Nicolas Mailhot wrote: > > > And then a full release upgrade would just be > > > 1. update packages via yum > > > 2. the new fedora-release file depends on one or several firstboot > > > packages, which are therefore installed during the yum upgrade > > > 3. on installation these packages create a "distro upgrade" bootloader > > > entry, make it default and ask to reboot > > > 4. user reboots on this entry and the actions which can not be done on a > > > live system are performed. > > > > Except what happens when one of the packages you're updating requires > > some of the other changes that would have to be done by one your > > "firstboot packages"? This isn't some sort of philosophical debate -- > > it's something that comes up at least every other release if not every > > release. > I won't say such a thing does not exist, but continuous yumable rolling > rawhide would not be possible in this case, and my experience is you can > "forget" to go through anaconda most of the releases. Haven't ever seen a "continuous yumable rolling rawhide". Not for any longish strech of time, in any case. More "rollercoaster" than "rolling", in any case. ;-) [No, I am /not/ complaining! Rawhide is wonderful... when it works ;-] -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From skvidal at phy.duke.edu Fri Dec 2 03:40:08 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 01 Dec 2005 22:40:08 -0500 Subject: Upgrades from one major release to the next In-Reply-To: <604aa7910512011758u302bd191ra14e69a6e88e361d@mail.gmail.com> References: <76e72f800512011730q322c9467w@mail.gmail.com> <1133488418.4054.33.camel@yoda.loki.me> <604aa7910512011758u302bd191ra14e69a6e88e361d@mail.gmail.com> Message-ID: <1133494808.17520.0.camel@cutter> On Thu, 2005-12-01 at 20:58 -0500, Jeff Spaleta wrote: > On 12/1/05, Jesse Keating wrote: > > IIRC the messages you see about .rpmsave and .rpmnew are issued by rpm, > > not by yum. > > Indeed.... i wish there was a way to log those messages in a > centralized way for review without having to screenscrape the stdout > scroll looking for them. I don't even think graphical up2date had/has > a way to review those messages. I think you could only see them if you > ran up2date from a terminal..back in the day. There's a way - it's been on the long list on yum for a while now to capture them for logging. -sv From tibbs at math.uh.edu Fri Dec 2 04:44:21 2005 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 01 Dec 2005 22:44:21 -0600 Subject: Upgrades from one major release to the next In-Reply-To: <76e72f800512011730q322c9467w@mail.gmail.com> (Yuan Yijun's message of "Fri, 2 Dec 2005 09:30:07 +0800") References: <76e72f800512011730q322c9467w@mail.gmail.com> Message-ID: >>>>> "YY" == Yuan Yijun writes: YY> If yum/rpm would send a detailed mail to all users indicate that YY> what configurations are saved to .rpmold, .rpmnew, etc. and what YY> are replaced then I could believe in yum/rpm more. I use the following script, which will tell you about any rpmsave or rpmnew files and can spam you with diffs as well. #!/usr/bin/perl use Getopt::Std; getopts('dq'); $| = 1; @DIFF = qw(/usr/bin/diff -u); @LS = qw(/bin/ls -l); @configfiles = `rpm -qac`; for $i (@configfiles) { chomp $i; $old = -f "$i.rpmsave"; $new = -f "$i.rpmnew"; if ($old || $new) { # If running quietly, we can just exit the first time we see a difference if ($opt_q) { exit 1; } $package = `rpm -qf $i`; chomp $package; push @{$updates{$package}}, {file => $i, old => $old, new => $new, }; } } exit 0 unless %updates; for $package (sort keys %updates) { print "Updated files in package $package:\n"; for $i (@{$updates{$package}}) { if ($i->{old}) { show ($i->{file}, "$i->{file}.rpmsave"); } if ($i->{new}) { show ($i->{file}, "$i->{file}.rpmnew"); } } print "\n"; } exit 1; sub show { my($old, $new) = @_; print " " if $opt_d; system(@LS, $old); print " " if $opt_d; system(@LS, $new); if ($opt_d) { print "Differences:\n", "="x40, "\n"; system(@DIFF, $old, $new); print "="x40, "\n"; } } - J< From naoki at valuecommerce.com Fri Dec 2 04:58:56 2005 From: naoki at valuecommerce.com (Naoki) Date: Fri, 02 Dec 2005 13:58:56 +0900 Subject: apache 2.2.0 Message-ID: <1133499537.453.99.camel@dragon.sys.intra> Any chance of this going into FC5? Or has the boat sailed? From pjones at redhat.com Fri Dec 2 05:13:43 2005 From: pjones at redhat.com (Peter Jones) Date: Fri, 02 Dec 2005 00:13:43 -0500 Subject: Pipe dreams: yum-based anaconda a step towards on-line yum-based upgrades? In-Reply-To: <20051201132751.1e9fabd3@python2> References: <20051130202605.GA7078@jadzia.bu.edu> <20051201132751.1e9fabd3@python2> Message-ID: <1133500423.2936.186.camel@localhost.localdomain> On Thu, 2005-12-01 at 13:27 +0100, Matthias Saou wrote: > Now... I know this is going to sound hackish and ugly, but why not have an > important Core package (say "fedora-release" for instance) obsolete these > removed packages up to their last known version? This still leaves the > opportunity to re-introduce them at a later date. Because that guarantees (no, *mandates*) that N -> N+2 upgrades won't work. If we're going to put this data some place other than anaconda, the answer is to put it in a package that tracks what needs this sort of special handling between updates, and to never take any of the data out. -- Peter From bbbush.yuan at gmail.com Fri Dec 2 06:49:50 2005 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Fri, 2 Dec 2005 14:49:50 +0800 Subject: Upgrades from one major release to the next In-Reply-To: References: <76e72f800512011730q322c9467w@mail.gmail.com> Message-ID: <76e72f800512012249r39c94368m@mail.gmail.com> 2005/12/2, Jason L Tibbitts III : > >>>>> "YY" == Yuan Yijun writes: Sincerely speaking I don't like to be called YY~~ (nor BB, MM alike please....What mail client are you running?) And I don't know if your script could help me, when and how frequently will you run this spam generator? After each yum cron job? :) Anyway, thank you very much! -- bbbush ^_^ From billcrawford1970 at gmail.com Fri Dec 2 08:26:03 2005 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 02 Dec 2005 08:26:03 +0000 Subject: yum update conflict today (FC4) In-Reply-To: References: Message-ID: <4390051B.3040606@googlemail.com> Rex Dieter wrote: > Rex Dieter wrote: >> Neal Becker wrote: >> >>> Transaction Check Error: file /usr/share/man/man1/gc.1.gz from >>> install of >>> libgc-devel-6.2-0.2.fc4.rf conflicts with file from package >>> graphviz-2.6-1.fc4 >> >> >> By that token, graphviz will conflict with Fedora Extras' gc-devel as >> well. > > Nevermind, gc-devel (IMO, correctly) places it's manpage in > /usr/share/man/man3/ > > Looks more like a bug in RPMForge's libgc, though I'm not sure of the > wisdom of their providing a package that FE already does (with > different naming). > > -- Rex > Perhaps they provided it first? From jorton at redhat.com Fri Dec 2 08:28:39 2005 From: jorton at redhat.com (Joe Orton) Date: Fri, 2 Dec 2005 08:28:39 +0000 Subject: apache 2.2.0 In-Reply-To: <1133499537.453.99.camel@dragon.sys.intra> References: <1133499537.453.99.camel@dragon.sys.intra> Message-ID: <20051202082839.GA18057@redhat.com> On Fri, Dec 02, 2005 at 01:58:56PM +0900, Naoki wrote: > Any chance of this going into FC5? Yup, coming soon! joe From billcrawford1970 at gmail.com Fri Dec 2 08:46:21 2005 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 02 Dec 2005 08:46:21 +0000 Subject: updatedb borked In-Reply-To: <438F0C2C.8030604@volny.cz> References: <20051201143632.22707.qmail@web51511.mail.yahoo.com> <438F0C2C.8030604@volny.cz> Message-ID: <439009DD.8090407@googlemail.com> Miloslav Trmac wrote: > I'm quite surprised nobody other has complained in the 20 days mlocate > is in rawhide ;-) > That would be because daily update was disabled by default some time ago, here :) From fedora at camperquake.de Fri Dec 2 09:01:00 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 2 Dec 2005 10:01:00 +0100 Subject: Pipe dreams: yum-based anaconda a step towards on-line yum-based upgrades? In-Reply-To: <200512020125.jB21PkxZ004566@pincoya.inf.utfsm.cl> References: <1133421703.14044.7.camel@rousalka.dyndns.org> <200512020125.jB21PkxZ004566@pincoya.inf.utfsm.cl> Message-ID: <20051202090100.GB939@ryoko.camperquake.de> On Thu, Dec 01, 2005 at 10:25:46PM -0300, Horst von Brand wrote: > [No, I am /not/ complaining! Rawhide is wonderful... when it works ;-] And most of the time it does, which continues to amaze me :) From benny+usenet at amorsen.dk Fri Dec 2 11:02:00 2005 From: benny+usenet at amorsen.dk (Benny Amorsen) Date: 02 Dec 2005 12:02:00 +0100 Subject: status of up2date and rhn-applet References: <1132852511.3748.7.camel@yoda.loki.me> <50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr> <1132983547.2860.32.camel@bree.local.net> <1133023655l.3593l.6l@serve.riede.org> <20051129075855.GB13739@neu.nirvana> <20051201113622.GP13775@neu.nirvana> Message-ID: >>>>> "AT" == Axel Thimm writes: AT> I really wonder what makes accepting "package replacements" so AT> hard, when you accept "kernel functionality replacement". If I AT> were to fear about destabilisation of my system, then I would AT> place avoiding kernel modules at number 1. When I later upgrade to FC5, I can be reasonably sure that breakage will be limited to the areas where I assumed the risk. In the case of the kernel module, there will be no breakage at all, since the ipw2200-module will be for an obsolete package by then. It is not stability of the system (as in, no random OOPSes) that I am concerned about. I just want a system that stays close to Fedora Core + Extras, so that I can count on the community around Fedora Core + Extras. I think Fedora + ATrpms is different enough to count as a separate distribution -- one that I have no interest in running. The same goes for Fedora + Livna and a few other large repositories. Fedora ATrpms has a significantly smaller community around it than Fedora Core + Extras does. /Benny From Axel.Thimm at ATrpms.net Fri Dec 2 11:24:02 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 2 Dec 2005 12:24:02 +0100 Subject: status of up2date and rhn-applet In-Reply-To: References: <1132852511.3748.7.camel@yoda.loki.me> <50061.194.94.224.254.1132912499.squirrel@jose.freesurf.fr> <1132983547.2860.32.camel@bree.local.net> <1133023655l.3593l.6l@serve.riede.org> <20051129075855.GB13739@neu.nirvana> <20051201113622.GP13775@neu.nirvana> Message-ID: <20051202112402.GE19554@neu.nirvana> On Fri, Dec 02, 2005 at 12:02:00PM +0100, Benny Amorsen wrote: > >>>>> "AT" == Axel Thimm writes: > > AT> I really wonder what makes accepting "package replacements" so > AT> hard, when you accept "kernel functionality replacement". If I > AT> were to fear about destabilisation of my system, then I would > AT> place avoiding kernel modules at number 1. > > When I later upgrade to FC5, I can be reasonably sure that breakage > will be limited to the areas where I assumed the risk. In the case of > the kernel module, there will be no breakage at all, since the > ipw2200-module will be for an obsolete package by then. > > It is not stability of the system (as in, no random OOPSes) that I am > concerned about. I just want a system that stays close to Fedora Core > + Extras, so that I can count on the community around Fedora Core + > Extras. > > I think Fedora + ATrpms is different enough to count as a separate > distribution There is no Fedora ATrpms Distribution. ATrpms is a software repository for Fedora Core and RHEL (and RHL, but these are all EOL now). > -- one that I have no interest in running. The same goes for Fedora > + Livna and a few other large repositories. Fedora ATrpms has a > significantly smaller community around it than Fedora Core + Extras > does. So let me encapsulate that: You don't want to use any repos outside of redhat.com, but you still do want to use single packages found in these repos. In such special filter cases, like someone asking for one single package from a (testing!) repository, I can only say that you will have to download that package(s) manually and take care of any explicit and implicit dependencies. No repo either at redhat.com, or externally, stable, testing or development, and no depsolver, how smart it may be, can have mechanisms for everyone's special needs. Otherwise there would be a subrepo per package. -- 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 Fri Dec 2 11:59:06 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 2 Dec 2005 12:59:06 +0100 Subject: Building FireFox 1.5 SRPMs on FC4... In-Reply-To: <438DE4EF.9040109@redhat.com> References: <1133368298.3357.63.camel@gilboa-home-dev.localhost> <438DE4EF.9040109@redhat.com> Message-ID: <20051202125906.240c6b1a@python2> Christopher Aillon wrote : > > Just wondering, I assume that FF 1.5 RPMs will be making their way into > > rawhide in the next couple of days. > > What are the chances of building their SRPMs on FC4? (x86-64 to be > > exact) > > Should I just give up and build the vanilla source package? > > Once the s390(x) builds finish, it should hit rawhide. I'd imagine you > should be able to build it on FC4 without issue, but why not try and > find out for sure? :-) I'm trying this too, and am running into major issues, related to my build environment : I'm using mock on an x86_64 machine, in an i386 chroot for the i386 builds. Well, the mozilla/firefox build seems to be pretty messed up, and messy in general, and I'm still fighting to try and *not* get the build to try and compile x86_64 code (and 64bit asm bits) inside the i386 root! First problem : The configure script set --host, --target and --build to x86_64-*. This is usually forced to the right target by %configure, which is not used here. Second problem : The configure "OS_TEST=`uname -m`" line causes 64bit asm to be used in xpcom/reflect/xptcall/src/md/unix/. Third problem : Build starts using -m64 and other x86_64 specific flags and files inside security/. I'm not sure where/why that starts yet, I'm still onto that one. IMHO, when Makefiles want to detect the CPU type, they should use what was passed as --target to the configure script, which isn't happening everywhere here. Should I file these issues as bugs (upstream, I guess), or are developers just not interested as long as it works for the general case (i.e. building on the arch the binary will be built for)? Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.14-1.1637_FC4 Load : 0.78 0.33 0.18 From fedora at camperquake.de Fri Dec 2 12:03:52 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Fri, 2 Dec 2005 13:03:52 +0100 Subject: Building FireFox 1.5 SRPMs on FC4... In-Reply-To: <20051202125906.240c6b1a@python2> References: <1133368298.3357.63.camel@gilboa-home-dev.localhost> <438DE4EF.9040109@redhat.com> <20051202125906.240c6b1a@python2> Message-ID: <20051202120352.GD939@ryoko.camperquake.de> On Fri, Dec 02, 2005 at 12:59:06PM +0100, Matthias Saou wrote: > Second problem : > The configure "OS_TEST=`uname -m`" line causes 64bit asm to be used in > xpcom/reflect/xptcall/src/md/unix/. Try running the build under setarch. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Dec 2 12:13:16 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 2 Dec 2005 13:13:16 +0100 Subject: Building FireFox 1.5 SRPMs on FC4... In-Reply-To: <20051202120352.GD939@ryoko.camperquake.de> References: <1133368298.3357.63.camel@gilboa-home-dev.localhost> <438DE4EF.9040109@redhat.com> <20051202125906.240c6b1a@python2> <20051202120352.GD939@ryoko.camperquake.de> Message-ID: <20051202131316.03c92332@python2> Ralf Ertzinger wrote : > On Fri, Dec 02, 2005 at 12:59:06PM +0100, Matthias Saou wrote: > > > Second problem : > > The configure "OS_TEST=`uname -m`" line causes 64bit asm to be used in > > xpcom/reflect/xptcall/src/md/unix/. > > Try running the build under setarch. Yeah, that's the proper "workaround", but still... when I force --target for a build, I expect it to be honored and not have "uname foo" run all over the place :-) Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.14-1.1637_FC4 Load : 0.63 0.55 0.41 From mattdm at mattdm.org Fri Dec 2 13:13:08 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Fri, 2 Dec 2005 08:13:08 -0500 Subject: Upgrades from one major release to the next In-Reply-To: <1133494808.17520.0.camel@cutter> References: <76e72f800512011730q322c9467w@mail.gmail.com> <1133488418.4054.33.camel@yoda.loki.me> <604aa7910512011758u302bd191ra14e69a6e88e361d@mail.gmail.com> <1133494808.17520.0.camel@cutter> Message-ID: <20051202131308.GA29096@jadzia.bu.edu> On Thu, Dec 01, 2005 at 10:40:08PM -0500, seth vidal wrote: > > scroll looking for them. I don't even think graphical up2date had/has > > a way to review those messages. I think you could only see them if you > > ran up2date from a terminal..back in the day. > There's a way - it's been on the long list on yum for a while now to > capture them for logging. Yeah I suck 'cause I keep promising to work on it. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From linville at redhat.com Fri Dec 2 13:16:27 2005 From: linville at redhat.com (John W. Linville) Date: Fri, 2 Dec 2005 08:16:27 -0500 Subject: Marvell 88E8053, sky2, and netdev In-Reply-To: <20051201145012.GG26698@redhat.com> References: <54045.66.224.116.99.1133434609.squirrel@www.okcforum.org> <20051201145012.GG26698@redhat.com> Message-ID: <20051202131627.GC5080@redhat.com> On Thu, Dec 01, 2005 at 09:50:12AM -0500, John W. Linville wrote: > On Thu, Dec 01, 2005 at 02:56:49AM -0800, Nathan Grennan wrote: > > I have a MSI K8N Neo4 Platinum motherboard. It includes a Marvell > > 88E8053 ethernet controller. From what I see online it seems the right > > driver is the sky2 driver. I see hints that it was in the netdev.2 > > package, but seems to be missing from the netdev.3 package. Has it been > > removed from netdev? Is it too unstable? Will it be coming back? Is > > there an alternative? > > Hmmm...not sure how that happened. I'll make sure it is in netdev.4. ...which is now available, in case you didn't see... -- John W. Linville linville at redhat.com From buildsys at redhat.com Fri Dec 2 14:27:51 2005 From: buildsys at redhat.com (Build System) Date: Fri, 2 Dec 2005 09:27:51 -0500 Subject: rawhide report: 20051202 changes Message-ID: <200512021427.jB2ERpAw023888@porkchop.devel.redhat.com> New package php-pear PHP Extension and Application Repository framework New package squashfs-tools squashfs utilities New package udapl A library for direct userspace use of RDMA protocols Updated Packages: NetworkManager-0.5.1-5 ---------------------- * Thu Dec 01 2005 John (J5) Palmieri - 0.5.1-5 - rebuild for new dbus anaconda-10.90.12-1 ------------------- * Thu Dec 01 2005 Jeremy Katz - 10.90.12-1 - some release notes viewer fixing (dcantrell) - allow %pre scripts in an %include (clumens, #166100) - fix the squashfs stuff to actually work - hack around slang not initializing utf8 mode so that we have line drawing chars (#174761) * Thu Dec 01 2005 Jeremy Katz - 10.90.11-1 - reworded media check prompt (dcantrell, #174472) - let's try squashfs... * Wed Nov 30 2005 Jeremy Katz - 10.90.10-1 - Don't split transactions on not split install types (pnasrat, #174033) - Fix None vs "" for vncpasswd in test mode (Patrick Mansfield) - Make release notes viewer as large as the screen (dcantrell) - Allow system-logos instead of fedora-logos for the package name - Try to build SELinux policy so that things work with selinux 2.x policy (#174563) apr-1.2.2-1 ----------- * Fri Dec 02 2005 Joe Orton 1.2.2-1 - update to 1.2.2 * Wed Nov 30 2005 Warren Togami 0.9.7-4 - rebuild against gcc-4.1.0 apr-util-1.2.2-1 ---------------- * Fri Nov 25 2005 Joe Orton 1.2.2-1 - update to 1.2.2 avahi-0.6-4 ----------- * Wed Nov 30 2005 Jason Vas Dias - 0.6-3 - fix bug 172047 - tools should require python-twisted - fix bug 173985 - docs directory permissions bind-24:9.3.1-26 ---------------- * Thu Dec 01 2005 Jason Vas Dias - 24:9.3.1-25 - rebuild for new dbus 0.6 dependency; remove use of DBUS_NAME_FLAG_PROHIBIT_REPLACEMENT bluez-pin-0.24-3 ---------------- * Thu Dec 01 2005 John (J5) Palmieri - 0.24-3 - rebuild for the new dbus bluez-utils-2.22-2 ------------------ * Thu Dec 01 2005 John (J5) Palmieri - 2.22-2 - rebuild for the new dbus checkpolicy-1.27.19-1 --------------------- * Thu Dec 01 2005 Dan Walsh 1.27.19-1 - Latest upgrade from NSA * Added error checking of all ebitmap_set_bit calls for out of memory conditions. * Merged removal of compatibility handling of netlink classes (requirement that policies with newer versions include the netlink class definitions, remapping of fine-grained netlink classes in newer source policies to single netlink class when generating older policies) from George Coker. chkconfig-1.3.25-1 ------------------ * Wed Nov 30 2005 Bill Nottingham 1.3.25-1 - return an error if changing services fails (#150235) control-center-1:2.13.2-1 ------------------------- * Fri Dec 02 2005 Matthias Clasen - 1:2.13.2-1 - Update to 2.13.2 cups-1:1.1.23-26 ---------------- * Thu Dec 01 2005 John (J5) Palmieri - 1:1.1.23-26 - rebuild for new dbus curl-7.15.0-3 ------------- * Wed Nov 30 2005 Ivana Varekova 7.15.0-3 - fix curl-config bug 174556 - missing vernum value dbus-0.60-1 ----------- * Thu Dec 01 2005 John (J5) Palmieri - 0.60-1 - upgrade to 0.60 desktop-printing-0.19-4 ----------------------- * Thu Dec 01 2005 John (J5) Palmieri - 0.19-4 - rebuild for new dbus dhcdbd-1.11-1.FC5 ----------------- * Thu Dec 01 2005 Jason Vas Dias 1.11-1 - Rebuild for new dbus-0.6 dependency; remove use of DBUS_NAME_FLAG_PROHIBIT_REPLACEMENT evince-0.4.0-3 -------------- * Thu Dec 01 2005 John (J5) Palmieri - 0.4.0-3 - rebuild for new dbus firstboot-1.3.54-1 ------------------ * Wed Nov 30 2005 Chris Lumens 1.3.54-1 - Use system-config-users for user/group/password validation (#174255). gdk-pixbuf-1:0.22.0-21 ---------------------- * Thu Dec 01 2005 Matthias Clasen - 1:0.22.0-21 - Fix path of rgb.txt gnome-applets-1:2.12.1-4 ------------------------ * Thu Dec 01 2005 John (J5) Palmieri - 1:2.12.1-4 - rebuild for new dbus gnome-power-manager-0.3.1-2 --------------------------- * Thu Dec 01 2005 John (J5) Palmieri - 0.3.1-2 - rebuild for new dbus gnome-screensaver-0.0.20-2 -------------------------- * Thu Dec 01 2005 John (J5) Palmieri - 0.0.20-2 - rebuild for new dbus gnome-system-monitor-2.13.2-1 ----------------------------- * Fri Dec 02 2005 Matthias Clasen 2.13.2-1 - Update to 2.13.2 gnome-utils-1:2.13.2-4 ---------------------- * Thu Dec 01 2005 John (J5) Palmieri - rebuild for new dbus gnome-vfs2-2.12.1.1-7 --------------------- * Thu Dec 01 2005 John (J5) Palmieri - 2.12.1.1-7 - rebuild for new dbus gnome-volume-manager-1.5.3-3 ---------------------------- * Thu Dec 01 2005 John (J5) Palmieri - 1.5.3-3 - rebuild for new dbus gnomemeeting-1.2.2-5 -------------------- * Wed Nov 30 2005 Alexander Larsson 1.2.2-5 - Rebuild for new openssl - enable deprecated ldap calls hal-0.5.5.1-2 ------------- * Thu Dec 01 2005 John (J5) Palmieri - 0.5.5.1-2 - Rebuild for dbus 0.60 hal-cups-utils-0.5.4-2 ---------------------- * Thu Dec 01 2005 John (J5) Palmieri - 0.5.4-2 - rebuild for new dbus kbd-1.12-12 ----------- * Thu Dec 01 2005 Miloslav Trmac - 1.12-12 - Don't reload the keymap in unicode_start (#172425) kdeaccessibility-1:3.5.0-1 -------------------------- * Thu Dec 01 2005 Than Ngo 1:3.5.0-1 - 3.5 kdebase-6:3.5.0-0.2.rc2 ----------------------- * Thu Dec 01 2005 Jeremy Katz - 6:3.5.0-0.2.rc2 - rebuild for new dbus kdegraphics-7:3.5.0-1 --------------------- * Wed Nov 30 2005 Than Ngo 7:3.5.0-1 - 3.5 kdelibs-6:3.5.0-1 ----------------- * Thu Dec 01 2005 Than Ngo 6:3.5.0-1 - add fix for modular X, thanks to Ville Skytt?? #174131 - probably fix #174541 kdemultimedia-6:3.5.0-1 ----------------------- * Tue Nov 29 2005 Than Ngo 6:3.5.0-1 - 3.5 final kdenetwork-7:3.5.0-1 -------------------- * Wed Nov 30 2005 Than Ngo 7:3.5.0-1 - 3.5 kdeutils-6:3.5.0-1 ------------------ * Wed Nov 30 2005 Than Ngo 6:3.5.0-1 - 3.5 kernel-2.6.14-1.1735_FC5 ------------------------ * Fri Dec 02 2005 Dave Jones - Better fix for the NFSD cache_change_attribute fix. (#174010) krb5-auth-dialog-0.5-2 ---------------------- * Thu Dec 01 2005 John (J5) Palmieri - 0.5-2 - rebuild for new dbus libbonobo-2.13.0-1 ------------------ * Thu Dec 01 2005 Matthias Clasen 2.13.0 - Update to 2.13.0 libbonoboui-2.13.0-1 -------------------- * Thu Dec 01 2005 Matthias Clasen - 2.13.0-1 - Update to 2.13.0 libc-client-2002e-18 -------------------- * Thu Dec 01 2005 Nalin Dahyabhai 2002e-18 - rebuild * Thu Dec 01 2005 Nalin Dahyabhai 2002e-17 - account for the /usr/share/ssl -> /etc/pki/tls move in the patch which sets the locations at compile-time (more of #165967) libgnome-2.13.2-1 ----------------- * Wed Nov 30 2005 Matthias Clasen - 2.13.2-1 - Update to 2.13.2 - Drop upstreamed patches * Mon Oct 24 2005 Matthias Clasen - 2.12.0.1-2 - Add schema for some new keys * Thu Sep 29 2005 Matthias Clasen - 2.12.0.1-1 - Update to 2.12.0.1 libgnomecups-0.2.2-3 -------------------- * Thu Dec 01 2005 John (J5) Palmieri - 0.2.2-3 - rebuild for new dbus libgsf-1.13.3-1 --------------- * Fri Dec 02 2005 Matthias Clasen 1.13.3-1 - Update to 1.13.3 libibverbs-1.0.rc4-0.4265.1.FC4 ------------------------------- libmthca-1.0.rc4-0.4265.1.FC5 ----------------------------- libsdp-0.90-0.4265.1.FC5 ------------------------ libselinux-1.27.28-1 -------------------- * Thu Dec 01 2005 Dan Walsh 1.27.28-1 - Update to latest from NSA * Added MATCHPATHCON_VALIDATE flag for set_matchpathcon_flags() and modified matchpathcon implementation to make context validation/ canonicalization optional at matchpathcon_init time, deferring it to a successful matchpathcon by default unless the new flag is set by the caller. * Added matchpathcon_init_prefix() interface, and reworked matchpathcon implementation to support selective loading of file contexts entries based on prefix matching between the pathname regex stems and the specified path prefix (stem must be a prefix of the specified path prefix). libwnck-2.13.2-1 ---------------- * Wed Nov 30 2005 Matthias Clasen - 2.13.2-1 - Update to 2.13.2 mc-1:4.6.1a-4 ------------- * Thu Dec 01 2005 Jindrich Novy 4.6.1a-4 - don't segfault when LANG is not set, thanks to Andy Shevchenko (#174070) - drop specsyntax patch, applied upstream - sync NVRE with Fedoras - depend on external slang [now updated to 2.0.5] (#174662) metacity-2.13.3-1 ----------------- * Thu Dec 01 2005 Matthias Clasen 2.13.3-1 - Update to 2.13.3 mlocate-0.11-2 -------------- * Fri Dec 02 2005 Miloslav Trmac - 0.11-2 - Comment out DAILY_UPDATE from updatedb.conf (#174693) nautilus-cd-burner-2.13.2-1 --------------------------- * Fri Dec 02 2005 Matthias Clasen 2.13.2-1 - Update to 2.13.2 * Thu Dec 01 2005 John (J5) Palmieri - 2.12.1-2 - rebuild for new dbus ncurses-5.4-22 -------------- * Thu Dec 01 2005 Petr Raszyk 5.4-22 - Rebuild. * Thu Dec 01 2005 Petr Raszyk 5.4-21 - Clear window after: filter()+'terminal-resizing'+endwin() doupdate()+endwin() See bug #174498, patch ncurses-5.4-endwinfilter.patch openh323-1.15.6-3 ----------------- * Thu Dec 01 2005 Alexander Larsson 1.15.6-3 - Rebuild with new openssl opensm-1.0-0.4265.1.FC5 ----------------------- perl-3:5.8.7-0.8.fc5 -------------------- * Thu Dec 01 2005 Jason Vas Dias - 3:5.8.7-0.8 - fix bug 174684 / CVE-2005-3962: sprintf integer overflow vulnerability backport upstream patch #26240 * Wed Nov 09 2005 Jason Vas Dias - 3:5.8.7-0.7 - fix bug 136009: restore MakeMaker support for LD_RUN_PATH, while removing empty LD_RUN_PATH * Tue Nov 08 2005 Jason Vas Dias - 3:5.8.7-0.7 - fix bug 172739: upstream bug 36521 : deep recursion and segfault in CGI::Carp::warn with 'use diagnostics' : applied patch 25160. - fix CAN-2004-0976: insecure use of temp files (ala Debian) php-5.1.1-2 ----------- * Mon Nov 28 2005 Joe Orton 5.1.1-2 - update to 5.1.1 - remove pear subpackage - enable pdo extensions (php-pdo subpackage) - remove non-standard conditional module builds - enable xmlreader extension pm-utils-0.07-3 --------------- * Thu Dec 01 2005 John (J5) Palmieri - 0.07-3 - rebuild for the new dbus rhythmbox-0.9.2-2 ----------------- * Thu Dec 01 2005 John (J5) Palmieri - rebuild for new dbus * Wed Nov 30 2005 Matthias Clasen - Update to 0.9.2 scim-anthy-0.8.0-1.fc5 ---------------------- * Thu Dec 01 2005 Akira TAGOH - 0.8.0-1 - New upstream release. selinux-doc-1.23.3-2 -------------------- * Thu Dec 01 2005 Dan Walsh 1.23.3-2 - Add README.MODULES to distribution * Thu Nov 17 2005 Dan Walsh 1.23.3-1 - Update to NSA Release version * Updated CREDITS. * Updated README.MODULES. selinux-policy-2.0.7-2 ---------------------- * Sat Nov 29 2003 Dan Walsh 2.0.7-2 - No longer installing policy.20 file, anaconda handles the building of the app. shared-mime-info-0.16.cvs20051201-1 ----------------------------------- * Thu Dec 01 2005 Matthias Clasen - 0.16.cvs20051201-1 - Incorporate upstream changes spamassassin-3.1.0-3.fc5 ------------------------ * Thu Dec 01 2005 Warren Togami - 3.1.0-3 - #174579 nls spamd init script (Rudolf Kastl) usermode-1.84-1 --------------- * Thu Dec 01 2005 Jindrich Novy 1.84-1 - usermode-gtk dialog stays always on top, thanks to Pierre Ossman (#80634) vnc-4.1.1-26 ------------ * Thu Dec 01 2005 Tim Waugh 4.1.1-26 - Apply patch to allow vncviewer window reparenting (bug #174640). - Build again on s390/s390x (bug #174569). * Thu Dec 01 2005 Tim Waugh 4.1.1-25 - Actually initialise the vnc extension in Xvnc. - Disable lbx. xchat-1:2.6.0-3 --------------- * Thu Dec 01 2005 John (J5) Palmieri - 1:2.6.0-3 - rebuild for new dbus xrestop-0.2-6 ------------- * Thu Dec 01 2005 Karsten Hopp 0.2-6 - fix build requirements Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 avahi-tools - 0.6-4.i386 requires python-twisted cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel = 0:2.6.14-1.1696_FC5 cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5smp cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 evolution - 2.4.1-8.i386 requires libdbus-1.so.1 evolution - 2.4.1-8.i386 requires libdbus-glib-1.so.1 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel = 0:2.6.14-1.1696_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 gnome-media - 2.12.0-2.i386 requires libnautilus-burn.so.2 gnome-python2-nautilus-cd-burner - 2.12.1-6.i386 requires libnautilus-burn.so.2 httpd - 2.0.54-16.i386 requires libapr-0.so.0 httpd - 2.0.54-16.i386 requires libaprutil-0.so.0 kdesdk - 3.4.92-2.i386 requires libapr-0.so.0 kdesdk - 3.4.92-2.i386 requires libaprutil-0.so.0 librsvg2 - 2.13.3-1.i386 requires libgsf-1.so.1 libwpd - 0.8.3-1.i386 requires libgsf-1.so.1 libwpd-tools - 0.8.3-1.i386 requires libgsf-1.so.1 mod_perl - 2.0.2-2.i386 requires libapr-0.so.0 mod_perl - 2.0.2-2.i386 requires libaprutil-0.so.0 rhythmbox - 0.9.2-2.i386 requires libnautilus-burn.so.2 sound-juicer - 2.11.91-1.i386 requires libnautilus-burn.so.2 subversion - 1.2.3-4.i386 requires libapr-0.so.0 subversion - 1.2.3-4.i386 requires libaprutil-0.so.0 subversion-javahl - 1.2.3-4.i386 requires libapr-0.so.0 subversion-javahl - 1.2.3-4.i386 requires libaprutil-0.so.0 subversion-perl - 1.2.3-4.i386 requires libapr-0.so.0 subversion-perl - 1.2.3-4.i386 requires libaprutil-0.so.0 subversion-ruby - 1.2.3-4.i386 requires libapr-0.so.0 subversion-ruby - 1.2.3-4.i386 requires libaprutil-0.so.0 Broken deps for ia64 ---------------------------------------------------------- avahi-tools - 0.6-4.ia64 requires python-twisted evolution - 2.4.1-8.ia64 requires libdbus-1.so.1()(64bit) evolution - 2.4.1-8.ia64 requires libdbus-glib-1.so.1()(64bit) gnome-media - 2.12.0-2.ia64 requires libnautilus-burn.so.2()(64bit) gnome-python2-nautilus-cd-burner - 2.12.1-6.ia64 requires libnautilus-burn.so.2()(64bit) httpd - 2.0.54-16.ia64 requires libaprutil-0.so.0()(64bit) httpd - 2.0.54-16.ia64 requires libapr-0.so.0()(64bit) k3b - 0.12.4-0.a.1.ia64 requires libdbus-qt-1.so.1()(64bit) k3b - 0.12.4-0.a.1.ia64 requires libdbus-1.so.1()(64bit) kdesdk - 3.4.92-2.ia64 requires libapr-0.so.0()(64bit) kdesdk - 3.4.92-2.ia64 requires libaprutil-0.so.0()(64bit) librsvg2 - 2.13.3-1.ia64 requires libgsf-1.so.1()(64bit) libwpd - 0.8.3-1.ia64 requires libgsf-1.so.1()(64bit) libwpd-tools - 0.8.3-1.ia64 requires libgsf-1.so.1()(64bit) mod_perl - 2.0.2-2.ia64 requires libapr-0.so.0()(64bit) mod_perl - 2.0.2-2.ia64 requires libaprutil-0.so.0()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs rhythmbox - 0.9.2-2.ia64 requires libnautilus-burn.so.2()(64bit) sound-juicer - 2.11.91-1.ia64 requires libnautilus-burn.so.2()(64bit) subversion - 1.2.3-4.ia64 requires libaprutil-0.so.0()(64bit) subversion - 1.2.3-4.ia64 requires libapr-0.so.0()(64bit) subversion-perl - 1.2.3-4.ia64 requires libaprutil-0.so.0()(64bit) subversion-perl - 1.2.3-4.ia64 requires libapr-0.so.0()(64bit) subversion-ruby - 1.2.3-4.ia64 requires libaprutil-0.so.0()(64bit) subversion-ruby - 1.2.3-4.ia64 requires libapr-0.so.0()(64bit) Broken deps for ppc ---------------------------------------------------------- avahi-tools - 0.6-4.ppc requires python-twisted cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 evolution - 2.4.1-8.ppc requires libdbus-1.so.1 evolution - 2.4.1-8.ppc requires libdbus-glib-1.so.1 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 gnome-media - 2.12.0-2.ppc requires libnautilus-burn.so.2 gnome-python2-nautilus-cd-burner - 2.12.1-6.ppc requires libnautilus-burn.so.2 httpd - 2.0.54-16.ppc requires libapr-0.so.0 httpd - 2.0.54-16.ppc requires libaprutil-0.so.0 kdesdk - 3.4.92-2.ppc requires libapr-0.so.0 kdesdk - 3.4.92-2.ppc requires libaprutil-0.so.0 librsvg2 - 2.13.3-1.ppc requires libgsf-1.so.1 libwpd - 0.8.3-1.ppc requires libgsf-1.so.1 libwpd-tools - 0.8.3-1.ppc requires libgsf-1.so.1 mod_perl - 2.0.2-2.ppc requires libapr-0.so.0 mod_perl - 2.0.2-2.ppc requires libaprutil-0.so.0 rhythmbox - 0.9.2-2.ppc requires libnautilus-burn.so.2 sound-juicer - 2.11.91-1.ppc requires libnautilus-burn.so.2 subversion - 1.2.3-4.ppc requires libapr-0.so.0 subversion - 1.2.3-4.ppc requires libaprutil-0.so.0 subversion-javahl - 1.2.3-4.ppc requires libapr-0.so.0 subversion-javahl - 1.2.3-4.ppc requires libaprutil-0.so.0 subversion-perl - 1.2.3-4.ppc requires libapr-0.so.0 subversion-perl - 1.2.3-4.ppc requires libaprutil-0.so.0 subversion-ruby - 1.2.3-4.ppc requires libapr-0.so.0 subversion-ruby - 1.2.3-4.ppc requires libaprutil-0.so.0 Broken deps for ppc64 ---------------------------------------------------------- avahi-tools - 0.6-4.ppc64 requires python-twisted cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi evolution - 2.4.1-8.ppc64 requires libdbus-1.so.1()(64bit) evolution - 2.4.1-8.ppc64 requires libdbus-glib-1.so.1()(64bit) gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 gnome-media - 2.12.0-2.ppc64 requires libnautilus-burn.so.2()(64bit) gnome-python2-nautilus-cd-burner - 2.12.1-6.ppc64 requires libnautilus-burn.so.2()(64bit) httpd - 2.0.54-16.ppc64 requires libaprutil-0.so.0()(64bit) httpd - 2.0.54-16.ppc64 requires libapr-0.so.0()(64bit) k3b - 0.12.4-0.a.1.ppc64 requires libdbus-qt-1.so.1()(64bit) k3b - 0.12.4-0.a.1.ppc64 requires libdbus-1.so.1()(64bit) kdesdk - 3.4.92-2.ppc64 requires libapr-0.so.0()(64bit) kdesdk - 3.4.92-2.ppc64 requires libaprutil-0.so.0()(64bit) librsvg2 - 2.13.3-1.ppc64 requires libgsf-1.so.1()(64bit) libwpd - 0.8.3-1.ppc64 requires libgsf-1.so.1()(64bit) libwpd-tools - 0.8.3-1.ppc64 requires libgsf-1.so.1()(64bit) mod_perl - 2.0.2-2.ppc64 requires libapr-0.so.0()(64bit) mod_perl - 2.0.2-2.ppc64 requires libaprutil-0.so.0()(64bit) rhythmbox - 0.9.2-2.ppc64 requires libnautilus-burn.so.2()(64bit) sound-juicer - 2.11.91-1.ppc64 requires libnautilus-burn.so.2()(64bit) subversion - 1.2.3-4.ppc64 requires libaprutil-0.so.0()(64bit) subversion - 1.2.3-4.ppc64 requires libapr-0.so.0()(64bit) subversion-perl - 1.2.3-4.ppc64 requires libaprutil-0.so.0()(64bit) subversion-perl - 1.2.3-4.ppc64 requires libapr-0.so.0()(64bit) subversion-ruby - 1.2.3-4.ppc64 requires libaprutil-0.so.0()(64bit) subversion-ruby - 1.2.3-4.ppc64 requires libapr-0.so.0()(64bit) Broken deps for s390 ---------------------------------------------------------- avahi-tools - 0.6-4.s390 requires python-twisted evolution - 2.4.1-8.s390 requires libdbus-1.so.1 evolution - 2.4.1-8.s390 requires libdbus-glib-1.so.1 httpd - 2.0.54-16.s390 requires libapr-0.so.0 httpd - 2.0.54-16.s390 requires libaprutil-0.so.0 kdesdk - 3.4.92-2.s390 requires libapr-0.so.0 kdesdk - 3.4.92-2.s390 requires libaprutil-0.so.0 librsvg2 - 2.13.3-1.s390 requires libgsf-1.so.1 libwpd - 0.8.3-1.s390 requires libgsf-1.so.1 libwpd-tools - 0.8.3-1.s390 requires libgsf-1.so.1 mod_perl - 2.0.2-2.s390 requires libapr-0.so.0 mod_perl - 2.0.2-2.s390 requires libaprutil-0.so.0 rhythmbox - 0.9.1-1.s390 requires libdbus-1.so.1 rhythmbox - 0.9.1-1.s390 requires libdbus-glib-1.so.1 subversion - 1.2.3-4.s390 requires libapr-0.so.0 subversion - 1.2.3-4.s390 requires libaprutil-0.so.0 subversion-perl - 1.2.3-4.s390 requires libapr-0.so.0 subversion-perl - 1.2.3-4.s390 requires libaprutil-0.so.0 subversion-ruby - 1.2.3-4.s390 requires libapr-0.so.0 subversion-ruby - 1.2.3-4.s390 requires libaprutil-0.so.0 Broken deps for s390x ---------------------------------------------------------- avahi-tools - 0.6-4.s390x requires python-twisted evolution - 2.4.1-8.s390x requires libdbus-1.so.1()(64bit) evolution - 2.4.1-8.s390x requires libdbus-glib-1.so.1()(64bit) httpd - 2.0.54-16.s390x requires libaprutil-0.so.0()(64bit) httpd - 2.0.54-16.s390x requires libapr-0.so.0()(64bit) kdesdk - 3.4.92-2.s390x requires libapr-0.so.0()(64bit) kdesdk - 3.4.92-2.s390x requires libaprutil-0.so.0()(64bit) librsvg2 - 2.13.3-1.s390x requires libgsf-1.so.1()(64bit) libwpd - 0.8.3-1.s390x requires libgsf-1.so.1()(64bit) libwpd-tools - 0.8.3-1.s390x requires libgsf-1.so.1()(64bit) mod_perl - 2.0.2-2.s390x requires libapr-0.so.0()(64bit) mod_perl - 2.0.2-2.s390x requires libaprutil-0.so.0()(64bit) rhythmbox - 0.9.1-1.s390x requires libdbus-1.so.1()(64bit) rhythmbox - 0.9.1-1.s390x requires libdbus-glib-1.so.1()(64bit) subversion - 1.2.3-4.s390x requires libaprutil-0.so.0()(64bit) subversion - 1.2.3-4.s390x requires libapr-0.so.0()(64bit) subversion-perl - 1.2.3-4.s390x requires libaprutil-0.so.0()(64bit) subversion-perl - 1.2.3-4.s390x requires libapr-0.so.0()(64bit) subversion-ruby - 1.2.3-4.s390x requires libaprutil-0.so.0()(64bit) subversion-ruby - 1.2.3-4.s390x requires libapr-0.so.0()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 avahi-tools - 0.6-4.x86_64 requires python-twisted cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 evolution - 2.4.1-8.x86_64 requires libdbus-1.so.1()(64bit) evolution - 2.4.1-8.x86_64 requires libdbus-glib-1.so.1()(64bit) gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 gnome-media - 2.12.0-2.x86_64 requires libnautilus-burn.so.2()(64bit) gnome-python2-nautilus-cd-burner - 2.12.1-6.x86_64 requires libnautilus-burn.so.2()(64bit) httpd - 2.0.54-16.x86_64 requires libaprutil-0.so.0()(64bit) httpd - 2.0.54-16.x86_64 requires libapr-0.so.0()(64bit) kdesdk - 3.4.92-2.x86_64 requires libapr-0.so.0()(64bit) kdesdk - 3.4.92-2.x86_64 requires libaprutil-0.so.0()(64bit) librsvg2 - 2.13.3-1.x86_64 requires libgsf-1.so.1()(64bit) libwpd - 0.8.3-1.i386 requires libgsf-1.so.1 libwpd - 0.8.3-1.x86_64 requires libgsf-1.so.1()(64bit) libwpd-tools - 0.8.3-1.x86_64 requires libgsf-1.so.1()(64bit) mod_perl - 2.0.2-2.x86_64 requires libapr-0.so.0()(64bit) mod_perl - 2.0.2-2.x86_64 requires libaprutil-0.so.0()(64bit) rhythmbox - 0.9.2-2.x86_64 requires libnautilus-burn.so.2()(64bit) sound-juicer - 2.11.91-1.x86_64 requires libnautilus-burn.so.2()(64bit) subversion - 1.2.3-4.x86_64 requires libaprutil-0.so.0()(64bit) subversion - 1.2.3-4.x86_64 requires libapr-0.so.0()(64bit) subversion-javahl - 1.2.3-4.x86_64 requires libaprutil-0.so.0()(64bit) subversion-javahl - 1.2.3-4.x86_64 requires libapr-0.so.0()(64bit) subversion-perl - 1.2.3-4.x86_64 requires libaprutil-0.so.0()(64bit) subversion-perl - 1.2.3-4.x86_64 requires libapr-0.so.0()(64bit) subversion-ruby - 1.2.3-4.x86_64 requires libaprutil-0.so.0()(64bit) subversion-ruby - 1.2.3-4.x86_64 requires libapr-0.so.0()(64bit) From pnasrat at redhat.com Fri Dec 2 17:32:59 2005 From: pnasrat at redhat.com (Paul Nasrat) Date: Fri, 02 Dec 2005 12:32:59 -0500 Subject: Building FireFox 1.5 SRPMs on FC4... In-Reply-To: <20051202131316.03c92332@python2> References: <1133368298.3357.63.camel@gilboa-home-dev.localhost> <438DE4EF.9040109@redhat.com> <20051202125906.240c6b1a@python2> <20051202120352.GD939@ryoko.camperquake.de> <20051202131316.03c92332@python2> Message-ID: <1133544779.3078.4.camel@enki.eridu> On Fri, 2005-12-02 at 13:13 +0100, Matthias Saou wrote: > Ralf Ertzinger wrote : > > > On Fri, Dec 02, 2005 at 12:59:06PM +0100, Matthias Saou wrote: > > > > > Second problem : > > > The configure "OS_TEST=`uname -m`" line causes 64bit asm to be used in > > > xpcom/reflect/xptcall/src/md/unix/. > > > > Try running the build under setarch. > > Yeah, that's the proper "workaround", but still... when I force --target > for a build, I expect it to be honored and not have "uname foo" run all > over the place :-) It's already in bugzilla. Paul From dragoran at feuerpokemon.de Fri Dec 2 18:01:47 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Fri, 02 Dec 2005 19:01:47 +0100 Subject: Building FireFox 1.5 SRPMs on FC4... In-Reply-To: <1133544779.3078.4.camel@enki.eridu> References: <1133368298.3357.63.camel@gilboa-home-dev.localhost> <438DE4EF.9040109@redhat.com> <20051202125906.240c6b1a@python2> <20051202120352.GD939@ryoko.camperquake.de> <20051202131316.03c92332@python2> <1133544779.3078.4.camel@enki.eridu> Message-ID: <43908C0B.6080106@feuerpokemon.de> Paul Nasrat wrote: >On Fri, 2005-12-02 at 13:13 +0100, Matthias Saou wrote: > > >>Ralf Ertzinger wrote : >> >> >> >>>On Fri, Dec 02, 2005 at 12:59:06PM +0100, Matthias Saou wrote: >>> >>> >>> >>>>Second problem : >>>>The configure "OS_TEST=`uname -m`" line causes 64bit asm to be used in >>>>xpcom/reflect/xptcall/src/md/unix/. >>>> >>>> >>>Try running the build under setarch. >>> >>> >>Yeah, that's the proper "workaround", but still... when I force --target >>for a build, I expect it to be honored and not have "uname foo" run all >>over the place :-) >> >> > >It's already in bugzilla. > >Paul > > > it still does'nt build with setarch i386 rpmbuild -bb firefox.spec --target=i386 (it looks in lib64 for some libs) ... now builing it on my older athlonxp box... From sds at tycho.nsa.gov Fri Dec 2 19:17:16 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 02 Dec 2005 14:17:16 -0500 Subject: udev slowness and selinux In-Reply-To: References: Message-ID: <1133551036.28437.140.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2005-12-01 at 09:03 -0600, Jason Dravet wrote: > There has been some discussion on fedora-selinux-list about udev being > slowed by selinux. One of the comments about the slowest is the number of > nodes in /dev. Decrease the number of nodes in /dev and booting would be > faster. I checked my /dev directory and I think I have found some nodes > that are redundant. I have 32 ttySXX nodes in /dev. Please correct me if I > am wrong but ttyS is usually used for serial ports. On my system I have two > serial ports, both of which are disabled in the bios. I removed my modem > when I switched to DSL, so shouldn't there be 0 ttyS nodes? There are 64 > ttyXX nodes. Aren't these the virtual terminals I use to login locally? If > so shouldn't there only be 7 (Ctrl-F1 through Ctrl-F7)? > > The selinux-list group is looking into the issue, but I thought maybe until > a fix is available this is something that could be looked into. I could be > wrong and all of these nodes could be needed, but is so what are they used > for? It isn't the number of nodes in /dev; it is the number of entries in file_contexts. And the slowdown should be improved/eliminated with recent changes in libselinux (1.27.28); let us know if it isn't. There are two changes in libselinux, one of which will have immediate benefit without requiring any changes to udev, and the other of which requires a small change to udev to take advantage of. -- Stephen Smalley National Security Agency From nicolas.mailhot at laposte.net Fri Dec 2 19:20:42 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 02 Dec 2005 20:20:42 +0100 Subject: udev slowness and selinux In-Reply-To: <1133551036.28437.140.camel@moss-spartans.epoch.ncsc.mil> References: <1133551036.28437.140.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1133551245.3530.3.camel@rousalka.dyndns.org> Le vendredi 02 d?cembre 2005 ? 14:17 -0500, Stephen Smalley a ?crit : > It isn't the number of nodes in /dev; it is the number of entries in > file_contexts. And the slowdown should be improved/eliminated with > recent changes in libselinux (1.27.28); let us know if it isn't. There > are two changes in libselinux, one of which will have immediate benefit > without requiring any changes to udev, and the other of which requires a > small change to udev to take advantage of. BTW today's rawhide segfaults on boot if run in enforcing mode checkpolicy-1.27.19-1 selinux-policy-targeted-2.0.7-2 audit-1.1.1-1 audit-libs-1.1.1-1 audit-libs-1.1.1-1 libselinux-1.27.28-1 libselinux-1.27.28-1 libsepol-1.9.41-1 libsepol-1.9.41-1 libsemanage-1.3.61-1 Adding selinux=false to the boot arguments rescues the system 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 sds at tycho.nsa.gov Fri Dec 2 19:38:25 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 02 Dec 2005 14:38:25 -0500 Subject: udev slowness and selinux In-Reply-To: <1133551245.3530.3.camel@rousalka.dyndns.org> References: <1133551036.28437.140.camel@moss-spartans.epoch.ncsc.mil> <1133551245.3530.3.camel@rousalka.dyndns.org> Message-ID: <1133552305.28437.149.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-12-02 at 20:20 +0100, Nicolas Mailhot wrote: > Le vendredi 02 d?cembre 2005 ? 14:17 -0500, Stephen Smalley a ?crit : > > > It isn't the number of nodes in /dev; it is the number of entries in > > file_contexts. And the slowdown should be improved/eliminated with > > recent changes in libselinux (1.27.28); let us know if it isn't. There > > are two changes in libselinux, one of which will have immediate benefit > > without requiring any changes to udev, and the other of which requires a > > small change to udev to take advantage of. > > BTW today's rawhide segfaults on boot if run in enforcing mode > > checkpolicy-1.27.19-1 > selinux-policy-targeted-2.0.7-2 > audit-1.1.1-1 > audit-libs-1.1.1-1 > audit-libs-1.1.1-1 > libselinux-1.27.28-1 > libselinux-1.27.28-1 > libsepol-1.9.41-1 > libsepol-1.9.41-1 > libsemanage-1.3.61-1 > > Adding selinux=false to the boot arguments rescues the system Hmmm...same versions of the above, don't see this behavior. Details? -- Stephen Smalley National Security Agency From nicolas.mailhot at laposte.net Fri Dec 2 19:42:38 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 02 Dec 2005 20:42:38 +0100 Subject: udev slowness and selinux In-Reply-To: <1133552305.28437.149.camel@moss-spartans.epoch.ncsc.mil> References: <1133551036.28437.140.camel@moss-spartans.epoch.ncsc.mil> <1133551245.3530.3.camel@rousalka.dyndns.org> <1133552305.28437.149.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1133552561.3530.8.camel@rousalka.dyndns.org> Le vendredi 02 d?cembre 2005 ? 14:38 -0500, Stephen Smalley a ?crit : > On Fri, 2005-12-02 at 20:20 +0100, Nicolas Mailhot wrote: > > Le vendredi 02 d?cembre 2005 ? 14:17 -0500, Stephen Smalley a ?crit : > > > > > It isn't the number of nodes in /dev; it is the number of entries in > > > file_contexts. And the slowdown should be improved/eliminated with > > > recent changes in libselinux (1.27.28); let us know if it isn't. There > > > are two changes in libselinux, one of which will have immediate benefit > > > without requiring any changes to udev, and the other of which requires a > > > small change to udev to take advantage of. > > > > BTW today's rawhide segfaults on boot if run in enforcing mode > > > > checkpolicy-1.27.19-1 > > selinux-policy-targeted-2.0.7-2 > > audit-1.1.1-1 > > audit-libs-1.1.1-1 > > audit-libs-1.1.1-1 > > libselinux-1.27.28-1 > > libselinux-1.27.28-1 > > libsepol-1.9.41-1 > > libsepol-1.9.41-1 > > libsemanage-1.3.61-1 > > > > Adding selinux=false to the boot arguments rescues the system > > Hmmm...same versions of the above, don't see this behavior. Details? No :( Did a rawhide update (kernel + selinux stuff), touch ./autorelabel, reboot -> bang Tried the previous working kernel -> bang Rebooted on the rescue disk, nothing in the system logs (crash too early at selinux init) Since the last sync was only selinux-related, decided to try selinux=false before mucking with the system, and everything booted at once. Will try to reproduce now, in case it was a transient problem -- 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 Fri Dec 2 19:58:06 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 02 Dec 2005 20:58:06 +0100 Subject: udev slowness and selinux In-Reply-To: <1133552561.3530.8.camel@rousalka.dyndns.org> References: <1133551036.28437.140.camel@moss-spartans.epoch.ncsc.mil> <1133551245.3530.3.camel@rousalka.dyndns.org> <1133552305.28437.149.camel@moss-spartans.epoch.ncsc.mil> <1133552561.3530.8.camel@rousalka.dyndns.org> Message-ID: <1133553489.3645.3.camel@rousalka.dyndns.org> Le vendredi 02 d?cembre 2005 ? 20:42 +0100, Nicolas Mailhot a ?crit : > Le vendredi 02 d?cembre 2005 ? 14:38 -0500, Stephen Smalley a ?crit : > > Hmmm...same versions of the above, don't see this behavior. Details? > > No :( > Did a rawhide update (kernel + selinux stuff), touch ./autorelabel, > reboot -> bang > Tried the previous working kernel -> bang > Rebooted on the rescue disk, nothing in the system logs (crash too early > at selinux init) > > Since the last sync was only selinux-related, decided to try > selinux=false before mucking with the system, and everything booted at > once. > > Will try to reproduce now, in case it was a transient problem I can confirm - it's perfectly reproduceable. Boot -> bang. Add selinux=false via grub -> works I'll mail you privately a screenshot. 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 selinux at gmail.com Fri Dec 2 20:36:48 2005 From: selinux at gmail.com (Tom London) Date: Fri, 2 Dec 2005 12:36:48 -0800 Subject: udev slowness and selinux In-Reply-To: <1133553489.3645.3.camel@rousalka.dyndns.org> References: <1133551036.28437.140.camel@moss-spartans.epoch.ncsc.mil> <1133551245.3530.3.camel@rousalka.dyndns.org> <1133552305.28437.149.camel@moss-spartans.epoch.ncsc.mil> <1133552561.3530.8.camel@rousalka.dyndns.org> <1133553489.3645.3.camel@rousalka.dyndns.org> Message-ID: <4c4ba1530512021236y2173117ci32717c0eb4411bb9@mail.gmail.com> On 12/2/05, Nicolas Mailhot wrote: > Le vendredi 02 d?cembre 2005 ? 20:42 +0100, Nicolas Mailhot a ?crit : > > Le vendredi 02 d?cembre 2005 ? 14:38 -0500, Stephen Smalley a ?crit : > > > > Hmmm...same versions of the above, don't see this behavior. Details? > > > > No :( > > Did a rawhide update (kernel + selinux stuff), touch ./autorelabel, > > reboot -> bang > > Tried the previous working kernel -> bang > > Rebooted on the rescue disk, nothing in the system logs (crash too early > > at selinux init) > > > > Since the last sync was only selinux-related, decided to try > > selinux=false before mucking with the system, and everything booted at > > once. > > > > Will try to reproduce now, in case it was a transient problem > > I can confirm - it's perfectly reproduceable. Boot -> bang. Add > selinux=false via grub -> works > > I'll mail you privately a screenshot. > > Regards, > > -- > Nicolas Mailhot > Additional confirmation: update to latest policy (selinux-policy-targeted-2.0.7-2) yielded many avc and transition errors on boot. Rebooted in permissive and relabeled. rebooting in enforcing 'works', but lots of avcs: [root at tlondon ~]# ausearch -m avc,selinux_err -ts 12/02/2005 | audit2allow -l allow cupsd_t unlabeled_t:dir search; allow dhcpc_t system_dbusd_var_run_t:dir search; allow hald_t agp_device_t:chr_file getattr; allow hald_t clock_device_t:chr_file getattr; allow hald_t memory_device_t:chr_file getattr; allow hald_t ptmx_t:chr_file getattr; allow hald_t random_device_t:chr_file getattr; allow hald_t sound_device_t:chr_file getattr; allow hald_t tmpfs_t:chr_file getattr; allow hald_t tty_device_t:chr_file getattr; allow hald_t unlabeled_t:dir search; allow hald_t urandom_device_t:chr_file getattr; allow hald_t zero_device_t:chr_file getattr; allow kernel_t lib_t:file execmod; allow kernel_t texrel_shlib_t:file relabelto; allow kernel_t user_home_dir_t:dir relabelto; allow kernel_t user_home_t:dir relabelto; allow kernel_t user_home_t:file relabelto; allow kernel_t user_home_t:lnk_file relabelto; allow kernel_t user_home_t:sock_file relabelto; allow ntpd_t self:capability sys_resource; allow privoxy_t unlabeled_t:file getattr; allow system_dbusd_t unlabeled_t:dir read; allow unlabeled_t fs_t:filesystem associate; These known? Need the actual avcs? tom -- Tom London From sds at tycho.nsa.gov Fri Dec 2 22:09:44 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 02 Dec 2005 17:09:44 -0500 Subject: udev slowness and selinux In-Reply-To: <4c4ba1530512021236y2173117ci32717c0eb4411bb9@mail.gmail.com> References: <1133551036.28437.140.camel@moss-spartans.epoch.ncsc.mil> <1133551245.3530.3.camel@rousalka.dyndns.org> <1133552305.28437.149.camel@moss-spartans.epoch.ncsc.mil> <1133552561.3530.8.camel@rousalka.dyndns.org> <1133553489.3645.3.camel@rousalka.dyndns.org> <4c4ba1530512021236y2173117ci32717c0eb4411bb9@mail.gmail.com> Message-ID: <1133561384.28437.158.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-12-02 at 12:36 -0800, Tom London wrote: > Additional confirmation: > > update to latest policy (selinux-policy-targeted-2.0.7-2) yielded many > avc and transition errors on boot. > > Rebooted in permissive and relabeled. > > rebooting in enforcing 'works', but lots of avcs: > [root at tlondon ~]# ausearch -m avc,selinux_err -ts 12/02/2005 | audit2allow -l > allow cupsd_t unlabeled_t:dir search; > allow dhcpc_t system_dbusd_var_run_t:dir search; > allow hald_t agp_device_t:chr_file getattr; > allow hald_t clock_device_t:chr_file getattr; > allow hald_t memory_device_t:chr_file getattr; > allow hald_t ptmx_t:chr_file getattr; > allow hald_t random_device_t:chr_file getattr; > allow hald_t sound_device_t:chr_file getattr; > allow hald_t tmpfs_t:chr_file getattr; > allow hald_t tty_device_t:chr_file getattr; > allow hald_t unlabeled_t:dir search; > allow hald_t urandom_device_t:chr_file getattr; > allow hald_t zero_device_t:chr_file getattr; > allow kernel_t lib_t:file execmod; > allow kernel_t texrel_shlib_t:file relabelto; > allow kernel_t user_home_dir_t:dir relabelto; > allow kernel_t user_home_t:dir relabelto; > allow kernel_t user_home_t:file relabelto; > allow kernel_t user_home_t:lnk_file relabelto; > allow kernel_t user_home_t:sock_file relabelto; > allow ntpd_t self:capability sys_resource; > allow privoxy_t unlabeled_t:file getattr; > allow system_dbusd_t unlabeled_t:dir read; > allow unlabeled_t fs_t:filesystem associate; Strange, I don't see this either. I don't have the latest hald though (seems to be a dependency problem there). I'm running kernel-smp-2.6.14-1.1735_FC5 for what that's worth. Only audit messages during startup are (after audit2allow): allow hald_t tty_device_t:chr_file ioctl; allow updfstab_t tmpfs_t:dir getattr; What is unlabeled on your system (unlabeled_t denials)? -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Fri Dec 2 22:22:01 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 02 Dec 2005 17:22:01 -0500 Subject: udev slowness and selinux In-Reply-To: <1133561384.28437.158.camel@moss-spartans.epoch.ncsc.mil> References: <1133551036.28437.140.camel@moss-spartans.epoch.ncsc.mil> <1133551245.3530.3.camel@rousalka.dyndns.org> <1133552305.28437.149.camel@moss-spartans.epoch.ncsc.mil> <1133552561.3530.8.camel@rousalka.dyndns.org> <1133553489.3645.3.camel@rousalka.dyndns.org> <4c4ba1530512021236y2173117ci32717c0eb4411bb9@mail.gmail.com> <1133561384.28437.158.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1133562121.28437.162.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-12-02 at 17:09 -0500, Stephen Smalley wrote: > Strange, I don't see this either. I don't have the latest hald though > (seems to be a dependency problem there). I'm running > kernel-smp-2.6.14-1.1735_FC5 for what that's worth. Only audit messages > during startup are (after audit2allow): > allow hald_t tty_device_t:chr_file ioctl; > allow updfstab_t tmpfs_t:dir getattr; > > What is unlabeled on your system (unlabeled_t denials)? Ok, updated hal and all dependencies, rebooted. Still comes up fine (enforcing, targeted); only other denial was: allow system_dbusd_t self:process setcap; -- Stephen Smalley National Security Agency From czar at czarc.net Fri Dec 2 22:15:28 2005 From: czar at czarc.net (Gene C.) Date: Fri, 2 Dec 2005 17:15:28 -0500 Subject: udev slowness and selinux In-Reply-To: <1133551245.3530.3.camel@rousalka.dyndns.org> References: <1133551036.28437.140.camel@moss-spartans.epoch.ncsc.mil> <1133551245.3530.3.camel@rousalka.dyndns.org> Message-ID: <200512021715.28684.czar@czarc.net> On Friday 02 December 2005 14:20, Nicolas Mailhot wrote: > Le vendredi 02 d?cembre 2005 ? 14:17 -0500, Stephen Smalley a ?crit : > > It isn't the number of nodes in /dev; it is the number of entries in > > file_contexts. ?And the slowdown should be improved/eliminated with > > recent changes in libselinux (1.27.28); let us know if it isn't. ?There > > are two changes in libselinux, one of which will have immediate benefit > > without requiring any changes to udev, and the other of which requires a > > small change to udev to take advantage of. > > BTW today's rawhide segfaults on boot if run in enforcing mode > > checkpolicy-1.27.19-1 > selinux-policy-targeted-2.0.7-2 > audit-1.1.1-1 > audit-libs-1.1.1-1 > audit-libs-1.1.1-1 > libselinux-1.27.28-1 > libselinux-1.27.28-1 > libsepol-1.9.41-1 > libsepol-1.9.41-1 > libsemanage-1.3.61-1 > > Adding selinux=false to the boot arguments rescues the system I also see a kernel panic after today's updates if selinux=enforcing Reboot selinux=false single and change to selinux=permissive gets things working again. -- Gene From orion at cora.nwra.com Fri Dec 2 22:15:57 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Fri, 02 Dec 2005 15:15:57 -0700 Subject: text mode installs with FC5t1 ugly again Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Did my first FC5T1 install and I see that the text mode windows are lousy again. Is this expected at this point? - - Orion -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD4DBQFDkMecORnzrtFC2/sRAmfHAKCSObImU5EM/G6eAsh2U+HIuVSM4QCXdnBu EgXDWaPsdBA51dGhX8mJ7g== =kuTz -----END PGP SIGNATURE----- From dwalsh at redhat.com Fri Dec 2 22:50:37 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 02 Dec 2005 17:50:37 -0500 Subject: udev slowness and selinux In-Reply-To: <200512021715.28684.czar@czarc.net> References: <1133551036.28437.140.camel@moss-spartans.epoch.ncsc.mil> <1133551245.3530.3.camel@rousalka.dyndns.org> <200512021715.28684.czar@czarc.net> Message-ID: <4390CFBD.6060305@redhat.com> Gene C. wrote: > On Friday 02 December 2005 14:20, Nicolas Mailhot wrote: > >> Le vendredi 02 d?cembre 2005 ? 14:17 -0500, Stephen Smalley a ?crit : >> >>> It isn't the number of nodes in /dev; it is the number of entries in >>> file_contexts. And the slowdown should be improved/eliminated with >>> recent changes in libselinux (1.27.28); let us know if it isn't. There >>> are two changes in libselinux, one of which will have immediate benefit >>> without requiring any changes to udev, and the other of which requires a >>> small change to udev to take advantage of. >>> >> BTW today's rawhide segfaults on boot if run in enforcing mode >> >> checkpolicy-1.27.19-1 >> selinux-policy-targeted-2.0.7-2 >> audit-1.1.1-1 >> audit-libs-1.1.1-1 >> audit-libs-1.1.1-1 >> libselinux-1.27.28-1 >> libselinux-1.27.28-1 >> libsepol-1.9.41-1 >> libsepol-1.9.41-1 >> libsemanage-1.3.61-1 >> >> Adding selinux=false to the boot arguments rescues the system >> > > I also see a kernel panic after today's updates if selinux=enforcing > > Reboot selinux=false single > and change to selinux=permissive gets things working again. > Yesterday's policy package wiped out the policy.20 file, on yum update. We are no longer shipping policy.20 in the rpm, and the package post install creates it. Problem is the previous version was shipped with it and wipes it out on its post uninstall. Need to change the trigger on policy package to recreate policy.20. selinux-policy-*-2.0.7-3 fixes the problem. It is up on my people site ftp://people.redhat.com/dwalsh/SELinux/Fedora You can also do a semoudle -B /usr/share/selinux/targeted/base.pp to recreate the policy.20 file. Do not reboot until you fix this or else init will crash because you have no policy. -- From selinux at gmail.com Sat Dec 3 00:30:02 2005 From: selinux at gmail.com (Tom London) Date: Fri, 2 Dec 2005 16:30:02 -0800 Subject: udev slowness and selinux In-Reply-To: <4390CFBD.6060305@redhat.com> References: <1133551036.28437.140.camel@moss-spartans.epoch.ncsc.mil> <1133551245.3530.3.camel@rousalka.dyndns.org> <200512021715.28684.czar@czarc.net> <4390CFBD.6060305@redhat.com> Message-ID: <4c4ba1530512021630raf04427w4f9b18bed1b6f864@mail.gmail.com> On 12/2/05, Daniel J Walsh wrote: > Gene C. wrote: > > On Friday 02 December 2005 14:20, Nicolas Mailhot wrote: > > > >> Le vendredi 02 d?cembre 2005 ? 14:17 -0500, Stephen Smalley a ?crit : > >> > >>> It isn't the number of nodes in /dev; it is the number of entries in > >>> file_contexts. And the slowdown should be improved/eliminated with > >>> recent changes in libselinux (1.27.28); let us know if it isn't. There > >>> are two changes in libselinux, one of which will have immediate benefit > >>> without requiring any changes to udev, and the other of which requires a > >>> small change to udev to take advantage of. > >>> > >> BTW today's rawhide segfaults on boot if run in enforcing mode > >> > >> checkpolicy-1.27.19-1 > >> selinux-policy-targeted-2.0.7-2 > >> audit-1.1.1-1 > >> audit-libs-1.1.1-1 > >> audit-libs-1.1.1-1 > >> libselinux-1.27.28-1 > >> libselinux-1.27.28-1 > >> libsepol-1.9.41-1 > >> libsepol-1.9.41-1 > >> libsemanage-1.3.61-1 > >> > >> Adding selinux=false to the boot arguments rescues the system > >> > > > > I also see a kernel panic after today's updates if selinux=enforcing > > > > Reboot selinux=false single > > and change to selinux=permissive gets things working again. > > > Yesterday's policy package wiped out the policy.20 file, on yum update. > We are no longer shipping policy.20 in the rpm, and the package post > install creates it. Problem is the previous version was shipped with > it and wipes it out on its post uninstall. Need to change the trigger > on policy package to recreate policy.20. > > selinux-policy-*-2.0.7-3 fixes the problem. It is up on my people site > ftp://people.redhat.com/dwalsh/SELinux/Fedora > > You can also do a > semoudle -B /usr/share/selinux/targeted/base.pp to recreate the > policy.20 file. > > Do not reboot until you fix this or else init will crash because you > have no policy. > > -- No joy? [root at tlondon Downloads]# rpm -Uvh selinux-policy-targeted-2.0.8-1.noarch.rpm Preparing... ########################################### [100%] 1:selinux-policy-targeted########################################### [100%] libsepol.sepol_genbools_array: boolean allow_write_xshm no longer in policy libsepol.sepol_genbools_array: boolean i18n_input_disable_trans no longer in policy libsepol.sepol_genbools_array: boolean mail_readhome no longer in policy libsepol.sepol_genbools_array: boolean mail_writehome no longer in policy libsepol.sepol_genbools_array: boolean pppd_for_user no longer in policy libsepol.sepol_genbools_array: boolean system_dbusd_disable_trans no longer in policy /usr/sbin/load_policy: Can't load policy: Invalid argument libsemanage.semanage_reload_policy: load_policy returned error code 2. libsepol.sepol_genbools_array: boolean allow_write_xshm no longer in policy libsepol.sepol_genbools_array: boolean i18n_input_disable_trans no longer in policy libsepol.sepol_genbools_array: boolean mail_readhome no longer in policy libsepol.sepol_genbools_array: boolean mail_writehome no longer in policy libsepol.sepol_genbools_array: boolean pppd_for_user no longer in policy libsepol.sepol_genbools_array: boolean system_dbusd_disable_trans no longer in policy /usr/sbin/load_policy: Can't load policy: Invalid argument libsemanage.semanage_reload_policy: load_policy returned error code 2. Failed! libsepol.sepol_genbools_array: boolean allow_write_xshm no longer in policy libsepol.sepol_genbools_array: boolean i18n_input_disable_trans no longer in policy libsepol.sepol_genbools_array: boolean mail_readhome no longer in policy libsepol.sepol_genbools_array: boolean mail_writehome no longer in policy libsepol.sepol_genbools_array: boolean pppd_for_user no longer in policy libsepol.sepol_genbools_array: boolean system_dbusd_disable_trans no longer in policy /usr/sbin/load_policy: Can't load policy: Invalid argument libsemanage.semanage_reload_policy: load_policy returned error code 2. libsepol.sepol_genbools_array: boolean allow_write_xshm no longer in policy libsepol.sepol_genbools_array: boolean i18n_input_disable_trans no longer in policy libsepol.sepol_genbools_array: boolean mail_readhome no longer in policy libsepol.sepol_genbools_array: boolean mail_writehome no longer in policy libsepol.sepol_genbools_array: boolean pppd_for_user no longer in policy libsepol.sepol_genbools_array: boolean system_dbusd_disable_trans no longer in policy /usr/sbin/load_policy: Can't load policy: Invalid argument libsemanage.semanage_reload_policy: load_policy returned error code 2. Failed! -- Tom London From selinux at gmail.com Sat Dec 3 03:07:03 2005 From: selinux at gmail.com (Tom London) Date: Fri, 2 Dec 2005 19:07:03 -0800 Subject: udev slowness and selinux In-Reply-To: <4c4ba1530512021630raf04427w4f9b18bed1b6f864@mail.gmail.com> References: <1133551036.28437.140.camel@moss-spartans.epoch.ncsc.mil> <1133551245.3530.3.camel@rousalka.dyndns.org> <200512021715.28684.czar@czarc.net> <4390CFBD.6060305@redhat.com> <4c4ba1530512021630raf04427w4f9b18bed1b6f864@mail.gmail.com> Message-ID: <4c4ba1530512021907i36ddd13bn4cbcd03d4982e7d8@mail.gmail.com> On 12/2/05, Tom London wrote: > On 12/2/05, Daniel J Walsh wrote: > > Gene C. wrote: > > > On Friday 02 December 2005 14:20, Nicolas Mailhot wrote: > > > > > >> Le vendredi 02 d?cembre 2005 ? 14:17 -0500, Stephen Smalley a ?crit : > > >> > > >>> It isn't the number of nodes in /dev; it is the number of entries in > > >>> file_contexts. And the slowdown should be improved/eliminated with > > >>> recent changes in libselinux (1.27.28); let us know if it isn't. There > > >>> are two changes in libselinux, one of which will have immediate benefit > > >>> without requiring any changes to udev, and the other of which requires a > > >>> small change to udev to take advantage of. > > >>> > > >> BTW today's rawhide segfaults on boot if run in enforcing mode > > >> > > >> checkpolicy-1.27.19-1 > > >> selinux-policy-targeted-2.0.7-2 > > >> audit-1.1.1-1 > > >> audit-libs-1.1.1-1 > > >> audit-libs-1.1.1-1 > > >> libselinux-1.27.28-1 > > >> libselinux-1.27.28-1 > > >> libsepol-1.9.41-1 > > >> libsepol-1.9.41-1 > > >> libsemanage-1.3.61-1 > > >> > > >> Adding selinux=false to the boot arguments rescues the system > > >> > > > > > > I also see a kernel panic after today's updates if selinux=enforcing > > > > > > Reboot selinux=false single > > > and change to selinux=permissive gets things working again. > > > > > Yesterday's policy package wiped out the policy.20 file, on yum update. > > We are no longer shipping policy.20 in the rpm, and the package post > > install creates it. Problem is the previous version was shipped with > > it and wipes it out on its post uninstall. Need to change the trigger > > on policy package to recreate policy.20. > > > > selinux-policy-*-2.0.7-3 fixes the problem. It is up on my people site > > ftp://people.redhat.com/dwalsh/SELinux/Fedora > > > > You can also do a > > semoudle -B /usr/share/selinux/targeted/base.pp to recreate the > > policy.20 file. > > > > Do not reboot until you fix this or else init will crash because you > > have no policy. > > > > -- > No joy? > > [root at tlondon Downloads]# rpm -Uvh selinux-policy-targeted-2.0.8-1.noarch.rpm > Preparing... ########################################### [100%] > 1:selinux-policy-targeted########################################### [100%] > libsepol.sepol_genbools_array: boolean allow_write_xshm no longer in policy > libsepol.sepol_genbools_array: boolean i18n_input_disable_trans no > longer in policy > libsepol.sepol_genbools_array: boolean mail_readhome no longer in policy > libsepol.sepol_genbools_array: boolean mail_writehome no longer in policy > libsepol.sepol_genbools_array: boolean pppd_for_user no longer in policy > libsepol.sepol_genbools_array: boolean system_dbusd_disable_trans no > longer in policy > /usr/sbin/load_policy: Can't load policy: Invalid argument > libsemanage.semanage_reload_policy: load_policy returned error code 2. > libsepol.sepol_genbools_array: boolean allow_write_xshm no longer in policy > libsepol.sepol_genbools_array: boolean i18n_input_disable_trans no > longer in policy > libsepol.sepol_genbools_array: boolean mail_readhome no longer in policy > libsepol.sepol_genbools_array: boolean mail_writehome no longer in policy > libsepol.sepol_genbools_array: boolean pppd_for_user no longer in policy > libsepol.sepol_genbools_array: boolean system_dbusd_disable_trans no > longer in policy > /usr/sbin/load_policy: Can't load policy: Invalid argument > libsemanage.semanage_reload_policy: load_policy returned error code 2. > Failed! > libsepol.sepol_genbools_array: boolean allow_write_xshm no longer in policy > libsepol.sepol_genbools_array: boolean i18n_input_disable_trans no > longer in policy > libsepol.sepol_genbools_array: boolean mail_readhome no longer in policy > libsepol.sepol_genbools_array: boolean mail_writehome no longer in policy > libsepol.sepol_genbools_array: boolean pppd_for_user no longer in policy > libsepol.sepol_genbools_array: boolean system_dbusd_disable_trans no > longer in policy > /usr/sbin/load_policy: Can't load policy: Invalid argument > libsemanage.semanage_reload_policy: load_policy returned error code 2. > libsepol.sepol_genbools_array: boolean allow_write_xshm no longer in policy > libsepol.sepol_genbools_array: boolean i18n_input_disable_trans no > longer in policy > libsepol.sepol_genbools_array: boolean mail_readhome no longer in policy > libsepol.sepol_genbools_array: boolean mail_writehome no longer in policy > libsepol.sepol_genbools_array: boolean pppd_for_user no longer in policy > libsepol.sepol_genbools_array: boolean system_dbusd_disable_trans no > longer in policy > /usr/sbin/load_policy: Can't load policy: Invalid argument > libsemanage.semanage_reload_policy: load_policy returned error code 2. > Failed! > Hmmm. Despite the above, rebooting 'works'. Relabeling now succeeds in 'catching' some unlabeled_t that did not get properly labeled before (e.g., /sbin/pam_console_apply). tom -- Tom London From notting at redhat.com Sat Dec 3 03:13:25 2005 From: notting at redhat.com (Bill Nottingham) Date: Fri, 2 Dec 2005 22:13:25 -0500 Subject: text mode installs with FC5t1 ugly again In-Reply-To: References: Message-ID: <20051203031325.GA2632@devserv.devel.redhat.com> Orion Poplawski (orion at cora.nwra.com) said: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Did my first FC5T1 install and I see that the text mode windows are > lousy again. Is this expected at this point? Known and fixed post-test1. Bill From fedora-devel-list at cygnusx-1.org Sat Dec 3 04:03:35 2005 From: fedora-devel-list at cygnusx-1.org (Nathan Grennan) Date: Fri, 02 Dec 2005 20:03:35 -0800 Subject: Marvell 88E8053, sky2, and netdev In-Reply-To: <20051202131627.GC5080@redhat.com> References: <54045.66.224.116.99.1133434609.squirrel@www.okcforum.org> <20051201145012.GG26698@redhat.com> <20051202131627.GC5080@redhat.com> Message-ID: <43911917.60603@cygnusx-1.org> John W. Linville wrote: > ...which is now available, in case you didn't see... > I noticed, and thank you. It works, and it is nice to see the port light up. On the flip side all I have to do to crash the system now is "service network restart". Unable to handle kernel NULL pointer dereference at 00000000000000e8 RIP: {:sky2:sky2_tx_complete+230} PGD 7d481067 PUD 796a7067 PMD 0 Oops: 0000 [1] CPU 0 Modules linked in: ipv6 dm_mirror dm_mod raid1 raid0 video button battery ac ohci1394 ieee1394 ohci_hcd ehci_hcd parport_pc parport i2c_nforce2 i2c_core shpchp snd_intel8x0 snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_emu10k1 snd_rawmidi snd_ac97_codec snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_ac97_bus snd_page_alloc snd_util_mem snd_hwdep snd soundcore sky2 8139too mii forcedeth floppy ext3 jbd sata_sil sata_nv libata sd_mod scsi_mod Pid: 3014, comm: ip Not tainted 2.6.14-1.1644_FC4.netdev.4 #1 RIP: 0010:[] {:sky2:sky2_tx_complete+230} RSP: 0018:ffffffff80493058 EFLAGS: 00010292 RAX: 0000000000020000 RBX: ffff81007e9a7800 RCX: 0000000000000001 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff81007fd41870 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: ffff81007e9a7c00 R13: ffff8100797d0000 R14: 0000000000000008 R15: 0000000000000008 FS: 00002aaaaaabf990(0000) GS:ffffffff804f9000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00000000000000e8 CR3: 0000000079658000 CR4: 00000000000006e0 Process ip (pid: 3014, threadinfo ffff810079036000, task ffff8100797f3800) Stack: ffffffff80154b00 ffff81007e9a7c28 ffff81007e9a7800 ffff81007e9a7800 ffff8100032384c0 0000000000000000 00000000ffff21c7 00007fffffa16f10 ffffffff80493188 ffffffff880ac20e Call Trace: {__do_IRQ+213} {:sky2:sky2_poll+1949} {ret_from_intr+0} {net_rx_action+154} {__do_softirq+74} {call_softirq+31} {do_softirq+44} {do_IRQ+52} {ret_from_intr+0} {dma_alloc_pages+71} {dma_alloc_pages+38} {dma_alloc_coherent+125} {:sky2:sky2_up+193} {dev_open+55} {dev_change_flags+99} {devinet_ioctl+671} {dev_ioctl+818} {sock_ioctl+656} {do_ioctl+27} {vfs_ioctl From alan at redhat.com Sat Dec 3 07:18:24 2005 From: alan at redhat.com (Alan Cox) Date: Sat, 3 Dec 2005 02:18:24 -0500 Subject: suggestion: move all java packages to extras In-Reply-To: <1133128006.6986.82.camel@localhost> References: <1133021599.17474.43.camel@cutter> <20051127054145.GA14718@dudweiler.stuttgart.redhat.com> <17289.50324.181961.701343@localhost.localdomain> <20051127151015.GA18926@jadzia.bu.edu> <1133105752.2853.14.camel@laptopd505.fenrus.org> <1133106791.21208.20.camel@cutter> <1133107847.2853.26.camel@laptopd505.fenrus.org> <4389E524.4050904@conversis.de> <1133115473.2853.36.camel@laptopd505.fenrus.org> <1133128006.6986.82.camel@localhost> Message-ID: <20051203071824.GA16906@devserv.devel.redhat.com> On Sun, Nov 27, 2005 at 04:46:46PM -0500, Michael Wiktowy wrote: > 1) those packages that enable network/Internet access and installation > of more packages > 2) those packages that people will likely use on systems that will never > have network/Internet access > Modem users would generally beg to differ, or those using GPRS, or with high bandwidth costs From buildsys at redhat.com Sat Dec 3 20:17:02 2005 From: buildsys at redhat.com (Build System) Date: Sat, 3 Dec 2005 15:17:02 -0500 Subject: rawhide report: 20051203 changes Message-ID: <200512032017.jB3KH2PK009901@porkchop.devel.redhat.com> Updated Packages: alsa-lib-1.0.10rf-2 ------------------- * Fri Dec 02 2005 Martin Stransky 1.0.10rf-2 - fix in spec file (#159046) avahi-0.6-5 ----------- * Fri Dec 02 2005 Jason Vas Dias - 0.6-5 - python-twisted has been removed from the FC-5 distribution - disable its use * Thu Dec 01 2005 Jason Vas Dias - 0.6-4 - Rebuild for dbus-0.6 - remove use of DBUS_NAME_FLAG_PROHIBIT_REPLACEMENT bind-28:9.3.2rc1-1 ------------------ * Fri Dec 02 2005 Jason Vas Dias - 28:9.3.2rc-1 - Upgrade to upstream version 9.3.2rc1 - fix namedSetForwarders -> namedGetForwarders SOURCE14 typo * Thu Dec 01 2005 Jason Vas Dias - 24:9.3.1-26 - rebuild for new dbus 0.6 dependency; remove use of DBUS_NAME_FLAG_PROHIBIT_REPLACEMENT * Wed Nov 23 2005 Jason Vas Dias - 24:9.3.1-24 - allow D-BUS support to work in bind-chroot environment: workaround latest selinux policy by mounting /var/run/dbus/ under chroot instead of /var/run/dbus/system-bus-socket device-mapper-1.02.02-1 ----------------------- * Fri Dec 02 2005 Peter Jones - 1.02.02-1 - update to 1.02.02 * Thu Dec 01 2005 Peter Jones - 1.01.05-4 - add api call to make device nodes explicitly, rather than the previous approach diffstat-1.41-1 --------------- * Fri Dec 02 2005 Tim Waugh 1.41-1 - 1.41. - Corrected URL. dmraid-1.0.0.rc9-FC5_3 ---------------------- * Fri Dec 02 2005 Peter Jones 1.0.0.rc9-FC5_3 - rebuild for device-mapper-1.02.02-1 epiphany-1.9.2-1 ---------------- * Fri Dec 02 2005 Matthias Clasen - 1.9.2-1 - Update to 1.9.2 - Package plugins evolution-data-server-1.4.2-1 ----------------------------- * Tue Nov 29 2005 David Malcolm - 1.4.2-1 - 1.4.2 fetchmail-6.3.0-1 ----------------- * Fri Dec 02 2005 Miloslav Trmac - 6.3.0-1 - Update to fetchmail-6.3.0 - Remove nohesiod and nokerberos conditionals file-roller-2.13.1-1 -------------------- * Thu Dec 01 2005 Matthias Clasen 2.13.1-1 - Update to 2.13.1 ftp-0.17-31 ----------- * Fri Dec 02 2005 Petr Raszyk - 0.17-31 - ftp does not close socket descriptor (if the remote file does not exist). See #174599, netkit-ftp-0.17-data.patch * Wed Oct 26 2005 Petr Raszyk - 0.17-30 - The patch netkit-ftp-0.17-C-Frame121.patch adds some comments/hints for C-Frame 121. It can be removed any time. gnome-applets-1:2.12.2-1 ------------------------ * Fri Dec 02 2005 Matthias Clasen 2.12.2-1 - Update to 2.12.2 gnome-games-1:2.13.2-1 ---------------------- * Thu Dec 01 2005 Matthias Clasen 1:2.13.2-1 - Update to 2.13.2 gnome-icon-theme-2.13.2-1 ------------------------- * Fri Dec 02 2005 Matthias Clasen - 2.13.2-1 - Update to 2.13.2 gnome-media-2.12.0-3 -------------------- * Fri Dec 02 2005 John (J5) Palmieri - 2.12.0-3 - Rebuild with new nautilus-cd-burner gnome-panel-2.13.2-1 -------------------- * Fri Dec 02 2005 Matthias Clasen 2.13.2-1 - Update to 2.13.2 gnome-python2-extras-2.12.1-7 ----------------------------- * Fri Dec 02 2005 John (J5) Palmieri - 2.12.1-7 - rebuild with new libnautilus-cd-burner gnome-speech-0.3.9-1 -------------------- * Fri Dec 02 2005 Matthias Clasen 0.3.9-1 - Update to 0.3.9 gnome-vfs2-2.13.1-1 ------------------- * Fri Dec 02 2005 Matthias Clasen - 2.13.1-1 - Update to 2.13.1 gnome-volume-manager-1.5.4-1 ---------------------------- * Fri Dec 02 2005 Matthias Clasen - 1.5.4-1 - Update to 1.5.4 gtksourceview-1.5.1-1 --------------------- * Thu Dec 01 2005 Matthias Clasen - 1.5.1-1 - Update to 1.5.1 httpd-2.2.0-1 ------------- * Fri Dec 02 2005 Joe Orton 2.2.0-1 - update to 2.2.0 * Wed Nov 30 2005 Joe Orton 2.1.10-2 - enable mod_authn_alias, mod_authn_anon - update default httpd.conf * Fri Nov 25 2005 Joe Orton 2.1.10-1 - update to 2.1.10 - require apr >= 1.2.0, apr-util >= 1.2.0 initscripts-8.18-1 ------------------ * Fri Dec 02 2005 Bill Nottingham 8.18-1 - use new dhclient file paths, add appropriate conflict (#169164) kernel-2.6.14-1.1737_FC5 ------------------------ * Fri Dec 02 2005 Dave Jones - 2.6.15-rc4-git1 - sysfs debug on x86-64 too. * Fri Dec 02 2005 Dave Jones - Better fix for the NFSD cache_change_attribute fix. (#174010) * Thu Dec 01 2005 Dave Jones - 2.6.15-rc4 - Flip default ioscheduler back to cfq. - Increase firmware loader timeout. (#174589) - Add sysfs debug info to oops output. libXt-0.99.2-3 -------------- * Fri Dec 02 2005 Kristian H??gsberg 0.99.2-3 - Use the default value from configure.ac for --with-xfile-search-path except with %{_datadir} instead of $(libdir), so Xt can search for app-default files as usual. - Move the --with-xfile-search-path outside the with_static condition. librsvg2-2.13.3-2 ----------------- * Fri Dec 02 2005 Matthias Clasen - 2.13.3-2 - Compile with svgz support libsetrans-0.1.9-1 ------------------ * Fri Dec 02 2005 Dan Walsh 0.1.9-1 - Handle multiple translations libuser-0.54.3-1 ---------------- * Fri Dec 02 2005 Miloslav Trmac - 0.54.3-1 - Fix crash in lpasswd when user is not specified (#174801) libwpd-0.8.3-2 -------------- * Fri Dec 02 2005 Caolan McNamara 0.8.3-2 - rebuild because of libwpd lvm2-2.02.01-1 -------------- * Fri Dec 02 2005 Peter Jones - 2.02.01-1 - update to 2.02.01 mod_perl-2.0.2-3 ---------------- * Fri Dec 02 2005 Joe Orton 2.0.2-3 - rebuild for httpd 2.2 mod_python-3.1.4-3 ------------------ * Fri Dec 02 2005 Joe Orton 3.1.4-3 - rebuild for httpd 2.2 - build with -fno-strict-aliasing - don't use deprecated APR_STATUS_IS_SUCCESS() macro nautilus-2.13.2-1 ----------------- * Fri Dec 02 2005 Matthias Clasen 2.13.2-1 - Update to 2.13.2 - Update patches * Tue Nov 01 2005 Alexander Larsson - 2.12.1-6 - Switch XFree86-devel buildrequirement to libX11-devel * Fri Oct 28 2005 Matthias Clasen 2.12.1-5 - Implement icon stretching keynav - Support formatting non-floppy devices openoffice.org-1:2.0.1-143.1.2 ------------------------------ * Fri Dec 02 2005 Caolan McNamara - 1:2.0.1-143.1 - 2.0.1 RC2 * Thu Dec 01 2005 Caolan McNamara - 1:2.0.1-0.142.4 - rh#174664# right click spellcheck came unstuck parted-1.6.25-5 --------------- * Fri Dec 02 2005 Peter Jones 1.6.25-5 - rebuild for new device-mapper * Thu Dec 01 2005 Peter Jones 1.6.25-4 - change device-mapper code to call dm_task_update_nodes() after tasks which change device nodes. php-5.1.1-3 ----------- * Fri Dec 02 2005 Joe Orton 5.1.1-3 - rebuild for httpd 2.2 policycoreutils-1.27.33-1 ------------------------- * Thu Dec 01 2005 Dan Walsh 1.27.31-1 - Update to match NSA * Merged audit2allow --tefile and --fcfile support from Dan Walsh. * Merged genhomedircon fix from Dan Walsh. * Merged semodule* man pages from Dan Walsh, and edited them. * Changed setfiles to set the MATCHPATHCON_VALIDATE flag to retain validation/canonicalization of contexts during init. redhat-menus-5.0.7-2 -------------------- * Fri Dec 02 2005 Jeremy Katz - 5.0.7-2 - hide system-config-packages from the applications menu until it works again rhnlib-2.0-1.p24.3 ------------------ * Wed Nov 30 2005 Mihai Ibanescu 2.0-1 - Fixed #165481 (setting socket timeouts causes uncaught SSL exceptions) - Fixed #143833 (memory leak in SSL, caused by the cert verification callback) - Finally incorporated patch from bug #135660 (basic HTTP authentication) * Fri Jul 01 2005 Joel Martin 1.8-7 - Allow spec file to be used without Makefile (for Solaris builds) * Mon Jul 19 2004 Mihai Ibanescu 1.8-6 - Fixed #128008 (internal _httplib, used with python 1.5.2, missed a HTTPResponse._read_chunked) - Fixed a typo rhpxl-0.8-1 ----------- * Fri Dec 02 2005 Chris Lumens 0.8-1 - Attempt to set hsync and vsync from the config file if probing fails (Maxim Dzumanenko - #154172). selinux-policy-2.0.8-1 ---------------------- * Fri Dec 02 2005 Dan Walsh 2.0.8-1. Update from upstream * Fri Dec 02 2005 Dan Walsh 2.0.7-3 - Also trigger to rebuild policy for versions up to 2.0.7. * Tue Nov 29 2005 Dan Walsh 2.0.7-2 - No longer installing policy.20 file, anaconda handles the building of the app. slang-2.0.5-5 ------------- * Fri Dec 02 2005 Petr Raszyk - 2.0.5-5 - A patch by Bill Nottingham (#174761). slang-LANG.patch slang reads automatically sh-env-variable LANG. sound-juicer-2.13.1-2 --------------------- * Fri Dec 02 2005 John (J5) Palmieri 2.13.1-2 - Rebuild with new libnautilus-cd-burner * Wed Aug 17 2005 Matthias Clasen 2.13.1-1 - Update to 2.13.1 subversion-1.2.3-5 ------------------ * Fri Dec 02 2005 Joe Orton 1.2.3-5 - rebuild for httpd-2.2/apr-1.2/apr-util-1.2 system-config-securitylevel-1.6.11-1 ------------------------------------ * Fri Dec 02 2005 Chris Lumens 1.6.11-1 - Support port ranges (#164187, #174281). - Restore longer description of https (#174249). systemtap-0.5-2 --------------- * Fri Dec 02 2005 Frank Eigler - 0.5-2 - Rebuilt for devel * Fri Dec 02 2005 Frank Ch. Eigler - 0.5-1 - Many fixes and improvements: 1425, 1536, 1505, 1380, 1329, 1828, 1271, 1339, 1340, 1345, 1837, 1917, 1903, 1336, 1868, 1594, 1564, 1276, 1295 * Mon Oct 31 2005 Roland McGrath - 0.4.2-1 - Many fixes and improvements: PRs 1344, 1260, 1330, 1295, 1311, 1368, 1182, 1131, 1332, 1366, 1456, 1271, 1338, 1482, 1477, 1194. Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 anaconda - 10.90.12-1.i386 requires libdevmapper.so.1.01(Base) anaconda - 10.90.12-1.i386 requires libdevmapper.so.1.01 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel = 0:2.6.14-1.1696_FC5 cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5smp cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 cryptsetup-luks-devel - 1.0.1-3.i386 requires libdevmapper.so.1.01(Base) cryptsetup-luks-devel - 1.0.1-3.i386 requires libdevmapper.so.1.01 device-mapper - 1.02.02-1.i386 requires libdevmapper.so.1.01(Base) device-mapper - 1.02.02-1.i386 requires libdevmapper.so.1.01 device-mapper-multipath - 0.4.4-2.4.i386 requires libdevmapper.so.1.01(Base) device-mapper-multipath - 0.4.4-2.4.i386 requires libdevmapper.so.1.01 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 evolution - 2.4.1-8.i386 requires libdbus-1.so.1 evolution - 2.4.1-8.i386 requires libdbus-glib-1.so.1 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel = 0:2.6.14-1.1696_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 kdesdk - 3.4.92-2.i386 requires libapr-0.so.0 kdesdk - 3.4.92-2.i386 requires libaprutil-0.so.0 kpartx - 0.4.4-2.4.i386 requires libdevmapper.so.1.01(Base) kpartx - 0.4.4-2.4.i386 requires libdevmapper.so.1.01 mod_auth_kerb - 5.0-7.i386 requires httpd-mmn = 0:20020903 mod_auth_mysql - 1:2.9.0-2.i386 requires httpd-mmn = 0:20020903 mod_auth_pgsql - 2.0.1-8.i386 requires httpd-mmn = 0:20020903 mod_authz_ldap - 0.26-4.i386 requires httpd-mmn = 0:20020903 mod_jk - 1.2.6-3jpp_4fc.i386 requires httpd-mmn = 0:20020903 python-pyblock - 0.6-1.i386 requires libdevmapper.so.1.01(Base) python-pyblock - 0.6-1.i386 requires libdevmapper.so.1.01 rhythmbox - 0.9.2-2.i386 requires libnautilus-burn.so.2 Broken deps for ia64 ---------------------------------------------------------- anaconda - 10.90.12-1.ia64 requires libdevmapper.so.1.01()(64bit) anaconda - 10.90.12-1.ia64 requires libdevmapper.so.1.01(Base)(64bit) cryptsetup-luks-devel - 1.0.1-3.ia64 requires libdevmapper.so.1.01(Base)(64bit) cryptsetup-luks-devel - 1.0.1-3.ia64 requires libdevmapper.so.1.01()(64bit) device-mapper - 1.02.02-1.ia64 requires libdevmapper.so.1.01()(64bit) device-mapper - 1.02.02-1.ia64 requires libdevmapper.so.1.01(Base)(64bit) device-mapper-multipath - 0.4.4-2.4.ia64 requires libdevmapper.so.1.01(Base)(64bit) device-mapper-multipath - 0.4.4-2.4.ia64 requires libdevmapper.so.1.01()(64bit) evolution - 2.4.1-8.ia64 requires libdbus-1.so.1()(64bit) evolution - 2.4.1-8.ia64 requires libdbus-glib-1.so.1()(64bit) k3b - 0.12.4-0.a.1.ia64 requires libdbus-qt-1.so.1()(64bit) k3b - 0.12.4-0.a.1.ia64 requires libdbus-1.so.1()(64bit) kdesdk - 3.4.92-2.ia64 requires libapr-0.so.0()(64bit) kdesdk - 3.4.92-2.ia64 requires libaprutil-0.so.0()(64bit) kpartx - 0.4.4-2.4.ia64 requires libdevmapper.so.1.01(Base)(64bit) kpartx - 0.4.4-2.4.ia64 requires libdevmapper.so.1.01()(64bit) mod_auth_kerb - 5.0-7.ia64 requires httpd-mmn = 0:20020903 mod_auth_mysql - 1:2.9.0-2.ia64 requires httpd-mmn = 0:20020903 mod_auth_pgsql - 2.0.1-8.ia64 requires httpd-mmn = 0:20020903 mod_authz_ldap - 0.26-4.ia64 requires httpd-mmn = 0:20020903 mod_jk - 1.2.6-3jpp_4fc.ia64 requires httpd-mmn = 0:20020903 python-pyblock - 0.6-1.ia64 requires libdevmapper.so.1.01(Base)(64bit) python-pyblock - 0.6-1.ia64 requires libdevmapper.so.1.01()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs rhythmbox - 0.9.2-2.ia64 requires libnautilus-burn.so.2()(64bit) Broken deps for ppc ---------------------------------------------------------- anaconda - 10.90.12-1.ppc requires libdevmapper.so.1.01(Base) anaconda - 10.90.12-1.ppc requires libdevmapper.so.1.01 cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 cryptsetup-luks-devel - 1.0.1-3.ppc requires libdevmapper.so.1.01(Base) cryptsetup-luks-devel - 1.0.1-3.ppc requires libdevmapper.so.1.01 device-mapper - 1.02.02-1.ppc requires libdevmapper.so.1.01(Base) device-mapper - 1.02.02-1.ppc requires libdevmapper.so.1.01 device-mapper-multipath - 0.4.4-2.4.ppc requires libdevmapper.so.1.01(Base) device-mapper-multipath - 0.4.4-2.4.ppc requires libdevmapper.so.1.01 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 evolution - 2.4.1-8.ppc requires libdbus-1.so.1 evolution - 2.4.1-8.ppc requires libdbus-glib-1.so.1 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 kdesdk - 3.4.92-2.ppc requires libapr-0.so.0 kdesdk - 3.4.92-2.ppc requires libaprutil-0.so.0 kpartx - 0.4.4-2.4.ppc requires libdevmapper.so.1.01(Base) kpartx - 0.4.4-2.4.ppc requires libdevmapper.so.1.01 mod_auth_kerb - 5.0-7.ppc requires httpd-mmn = 0:20020903 mod_auth_mysql - 1:2.9.0-2.ppc requires httpd-mmn = 0:20020903 mod_auth_pgsql - 2.0.1-8.ppc requires httpd-mmn = 0:20020903 mod_authz_ldap - 0.26-4.ppc requires httpd-mmn = 0:20020903 mod_jk - 1.2.6-3jpp_4fc.ppc requires httpd-mmn = 0:20020903 python-pyblock - 0.6-1.ppc requires libdevmapper.so.1.01(Base) python-pyblock - 0.6-1.ppc requires libdevmapper.so.1.01 rhythmbox - 0.9.2-2.ppc requires libnautilus-burn.so.2 Broken deps for ppc64 ---------------------------------------------------------- anaconda - 10.90.12-1.ppc64 requires libdevmapper.so.1.01()(64bit) anaconda - 10.90.12-1.ppc64 requires libdevmapper.so.1.01(Base)(64bit) cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 cryptsetup-luks-devel - 1.0.1-3.ppc64 requires libdevmapper.so.1.01()(64bit) cryptsetup-luks-devel - 1.0.1-3.ppc64 requires libdevmapper.so.1.01(Base)(64bit) device-mapper - 1.02.02-1.ppc64 requires libdevmapper.so.1.01(Base)(64bit) device-mapper - 1.02.02-1.ppc64 requires libdevmapper.so.1.01()(64bit) device-mapper-multipath - 0.4.4-2.4.ppc64 requires libdevmapper.so.1.01(Base)(64bit) device-mapper-multipath - 0.4.4-2.4.ppc64 requires libdevmapper.so.1.01()(64bit) dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi evolution - 2.4.1-8.ppc64 requires libdbus-1.so.1()(64bit) evolution - 2.4.1-8.ppc64 requires libdbus-glib-1.so.1()(64bit) gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 k3b - 0.12.4-0.a.1.ppc64 requires libdbus-qt-1.so.1()(64bit) k3b - 0.12.4-0.a.1.ppc64 requires libdbus-1.so.1()(64bit) kdesdk - 3.4.92-2.ppc64 requires libapr-0.so.0()(64bit) kdesdk - 3.4.92-2.ppc64 requires libaprutil-0.so.0()(64bit) kpartx - 0.4.4-2.4.ppc64 requires libdevmapper.so.1.01(Base)(64bit) kpartx - 0.4.4-2.4.ppc64 requires libdevmapper.so.1.01()(64bit) mod_auth_kerb - 5.0-7.ppc64 requires httpd-mmn = 0:20020903 mod_auth_mysql - 1:2.9.0-2.ppc64 requires httpd-mmn = 0:20020903 mod_auth_pgsql - 2.0.1-8.ppc64 requires httpd-mmn = 0:20020903 mod_authz_ldap - 0.26-4.ppc64 requires httpd-mmn = 0:20020903 mod_jk - 1.2.6-3jpp_4fc.ppc64 requires httpd-mmn = 0:20020903 python-pyblock - 0.6-1.ppc64 requires libdevmapper.so.1.01(Base)(64bit) python-pyblock - 0.6-1.ppc64 requires libdevmapper.so.1.01()(64bit) rhythmbox - 0.9.2-2.ppc64 requires libnautilus-burn.so.2()(64bit) Broken deps for s390 ---------------------------------------------------------- anaconda - 10.90.12-1.s390 requires libdevmapper.so.1.01(Base) anaconda - 10.90.12-1.s390 requires libdevmapper.so.1.01 cryptsetup-luks-devel - 1.0.1-3.s390 requires libdevmapper.so.1.01(Base) cryptsetup-luks-devel - 1.0.1-3.s390 requires libdevmapper.so.1.01 device-mapper - 1.02.02-1.s390 requires libdevmapper.so.1.01(Base) device-mapper - 1.02.02-1.s390 requires libdevmapper.so.1.01 device-mapper-multipath - 0.4.4-2.4.s390 requires libdevmapper.so.1.01(Base) device-mapper-multipath - 0.4.4-2.4.s390 requires libdevmapper.so.1.01 evolution - 2.4.1-8.s390 requires libdbus-1.so.1 evolution - 2.4.1-8.s390 requires libdbus-glib-1.so.1 kdesdk - 3.4.92-2.s390 requires libapr-0.so.0 kdesdk - 3.4.92-2.s390 requires libaprutil-0.so.0 kpartx - 0.4.4-2.4.s390 requires libdevmapper.so.1.01(Base) kpartx - 0.4.4-2.4.s390 requires libdevmapper.so.1.01 mod_auth_kerb - 5.0-7.s390 requires httpd-mmn = 0:20020903 mod_auth_mysql - 1:2.9.0-2.s390 requires httpd-mmn = 0:20020903 mod_auth_pgsql - 2.0.1-8.s390 requires httpd-mmn = 0:20020903 mod_authz_ldap - 0.26-4.s390 requires httpd-mmn = 0:20020903 mod_jk - 1.2.6-3jpp_4fc.s390 requires httpd-mmn = 0:20020903 rhythmbox - 0.9.1-1.s390 requires libdbus-1.so.1 rhythmbox - 0.9.1-1.s390 requires libdbus-glib-1.so.1 Broken deps for s390x ---------------------------------------------------------- anaconda - 10.90.12-1.s390x requires libdevmapper.so.1.01()(64bit) anaconda - 10.90.12-1.s390x requires libdevmapper.so.1.01(Base)(64bit) cryptsetup-luks-devel - 1.0.1-3.s390x requires libdevmapper.so.1.01()(64bit) cryptsetup-luks-devel - 1.0.1-3.s390x requires libdevmapper.so.1.01(Base)(64bit) device-mapper - 1.02.02-1.s390x requires libdevmapper.so.1.01()(64bit) device-mapper - 1.02.02-1.s390x requires libdevmapper.so.1.01(Base)(64bit) device-mapper - 1.02.02-1.s390 requires libdevmapper.so.1.01(Base) device-mapper - 1.02.02-1.s390 requires libdevmapper.so.1.01 device-mapper-multipath - 0.4.4-2.4.s390x requires libdevmapper.so.1.01(Base)(64bit) device-mapper-multipath - 0.4.4-2.4.s390x requires libdevmapper.so.1.01()(64bit) evolution - 2.4.1-8.s390x requires libdbus-1.so.1()(64bit) evolution - 2.4.1-8.s390x requires libdbus-glib-1.so.1()(64bit) kdesdk - 3.4.92-2.s390x requires libapr-0.so.0()(64bit) kdesdk - 3.4.92-2.s390x requires libaprutil-0.so.0()(64bit) kpartx - 0.4.4-2.4.s390x requires libdevmapper.so.1.01(Base)(64bit) kpartx - 0.4.4-2.4.s390x requires libdevmapper.so.1.01()(64bit) mod_auth_kerb - 5.0-7.s390x requires httpd-mmn = 0:20020903 mod_auth_mysql - 1:2.9.0-2.s390x requires httpd-mmn = 0:20020903 mod_auth_pgsql - 2.0.1-8.s390x requires httpd-mmn = 0:20020903 mod_authz_ldap - 0.26-4.s390x requires httpd-mmn = 0:20020903 mod_jk - 1.2.6-3jpp_4fc.s390x requires httpd-mmn = 0:20020903 rhythmbox - 0.9.1-1.s390x requires libdbus-1.so.1()(64bit) rhythmbox - 0.9.1-1.s390x requires libdbus-glib-1.so.1()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 anaconda - 10.90.12-1.x86_64 requires libdevmapper.so.1.01()(64bit) anaconda - 10.90.12-1.x86_64 requires libdevmapper.so.1.01(Base)(64bit) cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 cryptsetup-luks-devel - 1.0.1-3.x86_64 requires libdevmapper.so.1.01()(64bit) cryptsetup-luks-devel - 1.0.1-3.x86_64 requires libdevmapper.so.1.01(Base)(64bit) device-mapper - 1.02.02-1.i386 requires libdevmapper.so.1.01(Base) device-mapper - 1.02.02-1.i386 requires libdevmapper.so.1.01 device-mapper - 1.02.02-1.x86_64 requires libdevmapper.so.1.01()(64bit) device-mapper - 1.02.02-1.x86_64 requires libdevmapper.so.1.01(Base)(64bit) device-mapper-multipath - 0.4.4-2.4.x86_64 requires libdevmapper.so.1.01(Base)(64bit) device-mapper-multipath - 0.4.4-2.4.x86_64 requires libdevmapper.so.1.01()(64bit) dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 evolution - 2.4.1-8.x86_64 requires libdbus-1.so.1()(64bit) evolution - 2.4.1-8.x86_64 requires libdbus-glib-1.so.1()(64bit) gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 kdesdk - 3.4.92-2.x86_64 requires libapr-0.so.0()(64bit) kdesdk - 3.4.92-2.x86_64 requires libaprutil-0.so.0()(64bit) kpartx - 0.4.4-2.4.x86_64 requires libdevmapper.so.1.01(Base)(64bit) kpartx - 0.4.4-2.4.x86_64 requires libdevmapper.so.1.01()(64bit) mod_auth_kerb - 5.0-7.x86_64 requires httpd-mmn = 0:20020903 mod_auth_mysql - 1:2.9.0-2.x86_64 requires httpd-mmn = 0:20020903 mod_auth_pgsql - 2.0.1-8.x86_64 requires httpd-mmn = 0:20020903 mod_authz_ldap - 0.26-4.x86_64 requires httpd-mmn = 0:20020903 mod_jk - 1.2.6-3jpp_4fc.x86_64 requires httpd-mmn = 0:20020903 python-pyblock - 0.6-1.x86_64 requires libdevmapper.so.1.01(Base)(64bit) python-pyblock - 0.6-1.x86_64 requires libdevmapper.so.1.01()(64bit) rhythmbox - 0.9.2-2.x86_64 requires libnautilus-burn.so.2()(64bit) From mwiktowy at gmx.net Sat Dec 3 20:32:47 2005 From: mwiktowy at gmx.net (Michael Wiktowy) Date: Sat, 03 Dec 2005 15:32:47 -0500 Subject: suggestion: move all java packages to extras In-Reply-To: <20051203071824.GA16906@devserv.devel.redhat.com> References: <1133021599.17474.43.camel@cutter> <20051127054145.GA14718@dudweiler.stuttgart.redhat.com> <17289.50324.181961.701343@localhost.localdomain> <20051127151015.GA18926@jadzia.bu.edu> <1133105752.2853.14.camel@laptopd505.fenrus.org> <1133106791.21208.20.camel@cutter> <1133107847.2853.26.camel@laptopd505.fenrus.org> <4389E524.4050904@conversis.de> <1133115473.2853.36.camel@laptopd505.fenrus.org> <1133128006.6986.82.camel@localhost> <20051203071824.GA16906@devserv.devel.redhat.com> Message-ID: <1133641967.4885.20.camel@localhost> On Sat, 2005-12-03 at 02:18 -0500, Alan Cox wrote: > On Sun, Nov 27, 2005 at 04:46:46PM -0500, Michael Wiktowy wrote: > > 1) those packages that enable network/Internet access and installation > > of more packages > > 2) those packages that people will likely use on systems that will never > > have network/Internet access > > > > Modem users would generally beg to differ, or those using GPRS, or with high > bandwidth costs The spirit of group 2) is to include all those things in core that people would typically use that *effectively* don't have Internet access for the purposes of downloading extras. I would put the needs of modem users/low bandwidth users squarely in that group since it would be impractical for them to do any large transfers to enhance/update their system. They have to rely on out-of-band means for getting their base and add-ons anyways; just like people behind a restrictive corporate firewall or those with no NIC/modem/tin-can-with-string/carrier-pigeon at all. However, the fact that they have a little bit of usable bandwidth for some Internet activities does put some low-bandwidth intensive apps into group 2) and all the dial-up access apps in group 1) though. So your comments would add "modem users" as a target group for FC. /Mike From ellson at research.att.com Sat Dec 3 23:11:38 2005 From: ellson at research.att.com (John Ellson) Date: Sat, 03 Dec 2005 18:11:38 -0500 Subject: rawhide report: 20051203 changes In-Reply-To: <200512032017.jB3KH2PK009901@porkchop.devel.redhat.com> References: <200512032017.jB3KH2PK009901@porkchop.devel.redhat.com> Message-ID: <4392262A.30500@research.att.com> The package "dbus-qt" is no longer in fedora-devel, but attempting to remove it breaks a dependency from a package that is. # rpm -e dbus-qt error: Failed dependencies: libdbus-qt-1.so.1 is needed by (installed) kdebase-3.5.0-0.1.rc2.i386 This broken dependency was not included in today's list of broken dependencies. John From rdieter at math.unl.edu Sat Dec 3 23:58:38 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 03 Dec 2005 17:58:38 -0600 Subject: rawhide report: 20051203 changes In-Reply-To: <4392262A.30500@research.att.com> References: <200512032017.jB3KH2PK009901@porkchop.devel.redhat.com> <4392262A.30500@research.att.com> Message-ID: <4392312E.4030801@math.unl.edu> John Ellson wrote: > The package "dbus-qt" is no longer in fedora-devel, but attempting to > remove it breaks a dependency from a package that is. > > # rpm -e dbus-qt > error: Failed dependencies: > libdbus-qt-1.so.1 is needed by (installed) > kdebase-3.5.0-0.1.rc2.i386 > > This broken dependency was not included in today's list of broken > dependencies. IMO, the dbus dev's have chose to put the qt bindings back, so the dbus-qt package should come back too... (-: -- Rex From jrc at jrcormier.com Sun Dec 4 04:17:38 2005 From: jrc at jrcormier.com (Jean-Rene Cormier) Date: Sun, 04 Dec 2005 00:17:38 -0400 Subject: Rhythmbox with iPod support Message-ID: <1133669858.5569.4.camel@pluto.jrcormier.com> I was just wondering if Rhythmbox is gonna have support for iPod in FC5? I just compiled the Rhythmbox SRPMS from rawhide under FC4 and I needed libgpod which is not in rawhide so I'm assuming support for iPod in Rhythmbox won't be in FC5. Is there any reason preventing the inclusion of libgpod in FC? If not I think it would be nice to have it included to get iPod support in Rhythmbox out of the box ;) Thanks! -- Jean-Rene Cormier From jkeating at j2solutions.net Sun Dec 4 04:23:16 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 03 Dec 2005 20:23:16 -0800 Subject: Rhythmbox with iPod support In-Reply-To: <1133669858.5569.4.camel@pluto.jrcormier.com> References: <1133669858.5569.4.camel@pluto.jrcormier.com> Message-ID: <1133670196.3010.5.camel@yoda.loki.me> On Sun, 2005-12-04 at 00:17 -0400, Jean-Rene Cormier wrote: > > I was just wondering if Rhythmbox is gonna have support for iPod in FC5? > I just compiled the Rhythmbox SRPMS from rawhide under FC4 and I needed > libgpod which is not in rawhide so I'm assuming support for iPod in > Rhythmbox won't be in FC5. Is there any reason preventing the inclusion > of libgpod in FC? If not I think it would be nice to have it included to > get iPod support in Rhythmbox out of the box ;) > Could it be a plugin in extras? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From seg at haxxed.com Sun Dec 4 06:13:37 2005 From: seg at haxxed.com (Callum Lerwick) Date: Sun, 04 Dec 2005 00:13:37 -0600 Subject: disappointment over default acpid config In-Reply-To: <1131318839.9308.5.camel@localhost.localdomain> References: <1131303014.17044.4.camel@localhost.localdomain> <1131317853.17044.21.camel@localhost.localdomain> <604aa7910511061505u77368e9dif8dc1f04b0a08b37@mail.gmail.com> <1131318839.9308.5.camel@localhost.localdomain> Message-ID: <1133676817.30772.35.camel@localhost> There's something seriously wrong with the current design of g-p-m, yes. I have it set to suspend-to-disk my laptop when I hit the power button. I noticed when I'm not logged in, at the GDM login screen, it doesn't work. This is silly. Also, me and my wife share the laptop using GDM's flexible servers. What happens when two people are logged in? Three? Who's policy should be followed? Who gets to enforce policy? What needs to happen is a setup much like NetworkManager, there needs to be a PowerManager daemon that talks to HAL and carries out policy, and has nothing to do with X or Gnome. gnome-power-manager seems to be muddling three things: 1) configuring policy 2) carrying out policy 3) providing misc UI Number 1 should be handled by a system-config-power applet. Power management is screaming system-wide to me. Per-user seems ugly and wrong. I see little reason to have per-user configuration. (I guess this is mostly what gnome-power-preferences is currently doing?) Number 2 should be handled by a PowerManager daemon. Or hell, maybe just merge it all into the next generation init. (I already bitched about this earlier, and pm-scripts seems to be turning into yet another re-invention of what init/initscripts should be doing) Number 3 needs to just get blended into gnome. GUI options to suspend and hibernate should just be put right next to where you see "shut down" and "restart". And there's already a bazillion and one battery status applets. (Though I suppose g-p-m talks to HAL exclusively? Its also fairly pretty. Does it need to be a notification area applet? Once the policy enaction is torn out, can't it be made a native gnome applet? Let the KDE guys write their own HAL based battery applet.) From jrc at jrcormier.com Sun Dec 4 06:51:18 2005 From: jrc at jrcormier.com (Jean-Rene Cormier) Date: Sun, 04 Dec 2005 02:51:18 -0400 Subject: Rhythmbox with iPod support In-Reply-To: <1133670196.3010.5.camel@yoda.loki.me> References: <1133669858.5569.4.camel@pluto.jrcormier.com> <1133670196.3010.5.camel@yoda.loki.me> Message-ID: <1133679078.5569.18.camel@pluto.jrcormier.com> On Sat, 2005-12-03 at 20:23 -0800, Jesse Keating wrote: > On Sun, 2005-12-04 at 00:17 -0400, Jean-Rene Cormier wrote: > > > > I was just wondering if Rhythmbox is gonna have support for iPod in FC5? > > I just compiled the Rhythmbox SRPMS from rawhide under FC4 and I needed > > libgpod which is not in rawhide so I'm assuming support for iPod in > > Rhythmbox won't be in FC5. Is there any reason preventing the inclusion > > of libgpod in FC? If not I think it would be nice to have it included to > > get iPod support in Rhythmbox out of the box ;) > > > > Could it be a plugin in extras? I haven't seen any options to make a plugin for the different sources and libgpod is linked to the rhythmbox binary so I don't think a separate plugin in extras would be possible. I know that people want a smaller FC but libgpod isn't that big and it would add more functionality to something that's already in FC. -- Jean-Rene Cormier From jkeating at j2solutions.net Sun Dec 4 07:06:51 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 03 Dec 2005 23:06:51 -0800 Subject: Rhythmbox with iPod support In-Reply-To: <1133679078.5569.18.camel@pluto.jrcormier.com> References: <1133669858.5569.4.camel@pluto.jrcormier.com> <1133670196.3010.5.camel@yoda.loki.me> <1133679078.5569.18.camel@pluto.jrcormier.com> Message-ID: <1133680011.3010.12.camel@yoda.loki.me> On Sun, 2005-12-04 at 02:51 -0400, Jean-Rene Cormier wrote: > > I haven't seen any options to make a plugin for the different sources > and libgpod is linked to the rhythmbox binary so I don't think a > separate plugin in extras would be possible. I know that people want a > smaller FC but libgpod isn't that big and it would add more > functionality to something that's already in FC. Right. Just was curious. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From hughsient at gmail.com Sun Dec 4 09:06:56 2005 From: hughsient at gmail.com (Richard Hughes) Date: Sun, 04 Dec 2005 09:06:56 +0000 Subject: disappointment over default acpid config In-Reply-To: <1133676817.30772.35.camel@localhost> References: <1131303014.17044.4.camel@localhost.localdomain> <1131317853.17044.21.camel@localhost.localdomain> <604aa7910511061505u77368e9dif8dc1f04b0a08b37@mail.gmail.com> <1131318839.9308.5.camel@localhost.localdomain> <1133676817.30772.35.camel@localhost> Message-ID: <1133687216.2640.21.camel@localhost> On Sun, 2005-12-04 at 00:13 -0600, Callum Lerwick wrote: > There's something seriously wrong with the current design of g-p-m, yes. > I have it set to suspend-to-disk my laptop when I hit the power button. > I noticed when I'm not logged in, at the GDM login screen, it doesn't > work. This is silly. I know, It's being fixed. Please create a bugzilla and we can discuss the details there: http://www.gnome.org/projects/gnome-power-manager/bugs.html > Also, me and my wife share the laptop using GDM's > flexible servers. What happens when two people are logged in? Three? > Who's policy should be followed? Who ever is logged in at the moment. You can change this in /etc/dbus-1/system.d/hal.conf, and if no-one is logged in, then the policy of root. > Who gets to enforce policy? Anyone who can use org.freedesktop.Hal.Device.SystemPowerManagement can issue methods to HAL, and anyone can try to store policy. > What needs to happen is a setup much like NetworkManager, there needs to > be a PowerManager daemon that talks to HAL and carries out policy, and > has nothing to do with X or Gnome. Nope, been down this route, please see the archives: http://sourceforge.net/mailarchive/forum.php?forum=gnome-power-devel > gnome-power-manager seems to be muddling three things: > > 1) configuring policy > 2) carrying out policy > 3) providing misc UI > > Number 1 should be handled by a system-config-power applet. Power > management is screaming system-wide to me. Per-user seems ugly and > wrong. I see little reason to have per-user configuration. (I guess this > is mostly what gnome-power-preferences is currently doing?) Please see the g-p-m archives, this has been extensively discussed. > Number 2 should be handled by a PowerManager daemon. Or hell, maybe just > merge it all into the next generation init. (I already bitched about > this earlier, and pm-scripts seems to be turning into yet another > re-invention of what init/initscripts should be doing) I don't think we need any more init states. > Number 3 needs to just get blended into gnome. GUI options to suspend > and hibernate should just be put right next to where you see "shut down" > and "restart". Ohh I hope so too! Again, create a bugzilla for the (what component would be the logout window?), tell me the bugzilla number, and I can offer some sample code to integrate it with Hibernate and Suspend methods in HAL. We already know if the computer is able to suspend or hibernate (well, if support is compiled into the kernel, and that's no guarantee it's going to work...) and can trivially call a suspend_to_disk or suspend_to_ram with one dbus call. > And there's already a bazillion and one battery status > applets. (Though I suppose g-p-m talks to HAL exclusively? No, g-p-m can work with lots of other stuff talking to hal at the same time. > Its also fairly pretty. Thanks! > Does it need to be a notification area applet? Once the > policy enaction is torn out, can't it be made a native gnome applet? Let > the KDE guys write their own HAL based battery applet.) I'm sure the KDE guys can easily use the information and methods in HAL to improve the existing KDE pm-framework. I'm more than keen on this to happen. GNOME Applets do not do what I need at the moment, (see http://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174160 ) so until then we should use a notification icon. Richard. From dragoran at feuerpokemon.de Sun Dec 4 09:09:47 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Sun, 04 Dec 2005 10:09:47 +0100 Subject: apache 2.2.0 In-Reply-To: <1133499537.453.99.camel@dragon.sys.intra> References: <1133499537.453.99.camel@dragon.sys.intra> Message-ID: <4392B25B.1040902@feuerpokemon.de> Naoki wrote: >Any chance of this going into FC5? > >Or has the boat sailed? > > > looking at the schedule: http://fedora.redhat.com/participate/schedule/ the test2 devel freeze is on Dec 19 so there should be enough time to get it into test2 (and fc5 final ) From reuben-fedora-devel at reub.net Sun Dec 4 10:34:42 2005 From: reuben-fedora-devel at reub.net (Reuben Farrelly) Date: Sun, 04 Dec 2005 23:34:42 +1300 Subject: apache 2.2.0 In-Reply-To: <4392B25B.1040902@feuerpokemon.de> References: <1133499537.453.99.camel@dragon.sys.intra> <4392B25B.1040902@feuerpokemon.de> Message-ID: <4392C642.6080308@reub.net> On 4/12/2005 10:09 p.m., dragoran wrote: > Naoki wrote: > >> Any chance of this going into FC5? >> >> Or has the boat sailed? >> >> >> > looking at the schedule: > http://fedora.redhat.com/participate/schedule/ > the test2 devel freeze is on Dec 19 so there should be enough time to > get it into test2 (and fc5 final ) It's in rawhide now - in case you hadn't noticed...which means it's likely to be in FC5. By all accounts here Apache 2.1 + php 5.1 is good :) reuben From buildsys at redhat.com Sun Dec 4 11:42:42 2005 From: buildsys at redhat.com (Build System) Date: Sun, 4 Dec 2005 06:42:42 -0500 Subject: rawhide report: 20051204 changes Message-ID: <200512041142.jB4Bggwr020404@porkchop.devel.redhat.com> Updated Packages: kernel-2.6.14-1.1739_FC5 ------------------------ * Sun Dec 04 2005 Dave Jones - 2.6.15-rc5 * Sat Dec 03 2005 Dave Jones - 2.6.15-rc4-git2 * Fri Dec 02 2005 Dave Jones - 2.6.15-rc4-git1 - sysfs debug on x86-64 too. Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 anaconda - 10.90.12-1.i386 requires libdevmapper.so.1.01(Base) anaconda - 10.90.12-1.i386 requires libdevmapper.so.1.01 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel = 0:2.6.14-1.1696_FC5 cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5smp cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 cryptsetup-luks-devel - 1.0.1-3.i386 requires libdevmapper.so.1.01(Base) cryptsetup-luks-devel - 1.0.1-3.i386 requires libdevmapper.so.1.01 device-mapper - 1.02.02-1.i386 requires libdevmapper.so.1.01(Base) device-mapper - 1.02.02-1.i386 requires libdevmapper.so.1.01 device-mapper-multipath - 0.4.4-2.4.i386 requires libdevmapper.so.1.01(Base) device-mapper-multipath - 0.4.4-2.4.i386 requires libdevmapper.so.1.01 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 evolution - 2.4.1-8.i386 requires libdbus-1.so.1 evolution - 2.4.1-8.i386 requires libdbus-glib-1.so.1 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel = 0:2.6.14-1.1696_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 kdesdk - 3.4.92-2.i386 requires libapr-0.so.0 kdesdk - 3.4.92-2.i386 requires libaprutil-0.so.0 kpartx - 0.4.4-2.4.i386 requires libdevmapper.so.1.01(Base) kpartx - 0.4.4-2.4.i386 requires libdevmapper.so.1.01 mod_auth_kerb - 5.0-7.i386 requires httpd-mmn = 0:20020903 mod_auth_mysql - 1:2.9.0-2.i386 requires httpd-mmn = 0:20020903 mod_auth_pgsql - 2.0.1-8.i386 requires httpd-mmn = 0:20020903 mod_authz_ldap - 0.26-4.i386 requires httpd-mmn = 0:20020903 mod_jk - 1.2.6-3jpp_4fc.i386 requires httpd-mmn = 0:20020903 python-pyblock - 0.6-1.i386 requires libdevmapper.so.1.01(Base) python-pyblock - 0.6-1.i386 requires libdevmapper.so.1.01 rhythmbox - 0.9.2-2.i386 requires libnautilus-burn.so.2 Broken deps for ia64 ---------------------------------------------------------- anaconda - 10.90.12-1.ia64 requires libdevmapper.so.1.01()(64bit) anaconda - 10.90.12-1.ia64 requires libdevmapper.so.1.01(Base)(64bit) cryptsetup-luks-devel - 1.0.1-3.ia64 requires libdevmapper.so.1.01(Base)(64bit) cryptsetup-luks-devel - 1.0.1-3.ia64 requires libdevmapper.so.1.01()(64bit) device-mapper - 1.02.02-1.ia64 requires libdevmapper.so.1.01()(64bit) device-mapper - 1.02.02-1.ia64 requires libdevmapper.so.1.01(Base)(64bit) device-mapper-multipath - 0.4.4-2.4.ia64 requires libdevmapper.so.1.01(Base)(64bit) device-mapper-multipath - 0.4.4-2.4.ia64 requires libdevmapper.so.1.01()(64bit) evolution - 2.4.1-8.ia64 requires libdbus-1.so.1()(64bit) evolution - 2.4.1-8.ia64 requires libdbus-glib-1.so.1()(64bit) k3b - 0.12.4-0.a.1.ia64 requires libdbus-qt-1.so.1()(64bit) k3b - 0.12.4-0.a.1.ia64 requires libdbus-1.so.1()(64bit) kdesdk - 3.4.92-2.ia64 requires libapr-0.so.0()(64bit) kdesdk - 3.4.92-2.ia64 requires libaprutil-0.so.0()(64bit) kpartx - 0.4.4-2.4.ia64 requires libdevmapper.so.1.01(Base)(64bit) kpartx - 0.4.4-2.4.ia64 requires libdevmapper.so.1.01()(64bit) mod_auth_kerb - 5.0-7.ia64 requires httpd-mmn = 0:20020903 mod_auth_mysql - 1:2.9.0-2.ia64 requires httpd-mmn = 0:20020903 mod_auth_pgsql - 2.0.1-8.ia64 requires httpd-mmn = 0:20020903 mod_authz_ldap - 0.26-4.ia64 requires httpd-mmn = 0:20020903 mod_jk - 1.2.6-3jpp_4fc.ia64 requires httpd-mmn = 0:20020903 python-pyblock - 0.6-1.ia64 requires libdevmapper.so.1.01(Base)(64bit) python-pyblock - 0.6-1.ia64 requires libdevmapper.so.1.01()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs rhythmbox - 0.9.2-2.ia64 requires libnautilus-burn.so.2()(64bit) Broken deps for ppc ---------------------------------------------------------- anaconda - 10.90.12-1.ppc requires libdevmapper.so.1.01(Base) anaconda - 10.90.12-1.ppc requires libdevmapper.so.1.01 cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 cryptsetup-luks-devel - 1.0.1-3.ppc requires libdevmapper.so.1.01(Base) cryptsetup-luks-devel - 1.0.1-3.ppc requires libdevmapper.so.1.01 device-mapper - 1.02.02-1.ppc requires libdevmapper.so.1.01(Base) device-mapper - 1.02.02-1.ppc requires libdevmapper.so.1.01 device-mapper-multipath - 0.4.4-2.4.ppc requires libdevmapper.so.1.01(Base) device-mapper-multipath - 0.4.4-2.4.ppc requires libdevmapper.so.1.01 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 evolution - 2.4.1-8.ppc requires libdbus-1.so.1 evolution - 2.4.1-8.ppc requires libdbus-glib-1.so.1 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 kdesdk - 3.4.92-2.ppc requires libapr-0.so.0 kdesdk - 3.4.92-2.ppc requires libaprutil-0.so.0 kpartx - 0.4.4-2.4.ppc requires libdevmapper.so.1.01(Base) kpartx - 0.4.4-2.4.ppc requires libdevmapper.so.1.01 mod_auth_kerb - 5.0-7.ppc requires httpd-mmn = 0:20020903 mod_auth_mysql - 1:2.9.0-2.ppc requires httpd-mmn = 0:20020903 mod_auth_pgsql - 2.0.1-8.ppc requires httpd-mmn = 0:20020903 mod_authz_ldap - 0.26-4.ppc requires httpd-mmn = 0:20020903 mod_jk - 1.2.6-3jpp_4fc.ppc requires httpd-mmn = 0:20020903 python-pyblock - 0.6-1.ppc requires libdevmapper.so.1.01(Base) python-pyblock - 0.6-1.ppc requires libdevmapper.so.1.01 rhythmbox - 0.9.2-2.ppc requires libnautilus-burn.so.2 Broken deps for ppc64 ---------------------------------------------------------- anaconda - 10.90.12-1.ppc64 requires libdevmapper.so.1.01()(64bit) anaconda - 10.90.12-1.ppc64 requires libdevmapper.so.1.01(Base)(64bit) cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 cryptsetup-luks-devel - 1.0.1-3.ppc64 requires libdevmapper.so.1.01()(64bit) cryptsetup-luks-devel - 1.0.1-3.ppc64 requires libdevmapper.so.1.01(Base)(64bit) device-mapper - 1.02.02-1.ppc64 requires libdevmapper.so.1.01(Base)(64bit) device-mapper - 1.02.02-1.ppc64 requires libdevmapper.so.1.01()(64bit) device-mapper-multipath - 0.4.4-2.4.ppc64 requires libdevmapper.so.1.01(Base)(64bit) device-mapper-multipath - 0.4.4-2.4.ppc64 requires libdevmapper.so.1.01()(64bit) dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi evolution - 2.4.1-8.ppc64 requires libdbus-1.so.1()(64bit) evolution - 2.4.1-8.ppc64 requires libdbus-glib-1.so.1()(64bit) gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 k3b - 0.12.4-0.a.1.ppc64 requires libdbus-qt-1.so.1()(64bit) k3b - 0.12.4-0.a.1.ppc64 requires libdbus-1.so.1()(64bit) kdesdk - 3.4.92-2.ppc64 requires libapr-0.so.0()(64bit) kdesdk - 3.4.92-2.ppc64 requires libaprutil-0.so.0()(64bit) kpartx - 0.4.4-2.4.ppc64 requires libdevmapper.so.1.01(Base)(64bit) kpartx - 0.4.4-2.4.ppc64 requires libdevmapper.so.1.01()(64bit) mod_auth_kerb - 5.0-7.ppc64 requires httpd-mmn = 0:20020903 mod_auth_mysql - 1:2.9.0-2.ppc64 requires httpd-mmn = 0:20020903 mod_auth_pgsql - 2.0.1-8.ppc64 requires httpd-mmn = 0:20020903 mod_authz_ldap - 0.26-4.ppc64 requires httpd-mmn = 0:20020903 mod_jk - 1.2.6-3jpp_4fc.ppc64 requires httpd-mmn = 0:20020903 python-pyblock - 0.6-1.ppc64 requires libdevmapper.so.1.01(Base)(64bit) python-pyblock - 0.6-1.ppc64 requires libdevmapper.so.1.01()(64bit) rhythmbox - 0.9.2-2.ppc64 requires libnautilus-burn.so.2()(64bit) Broken deps for s390 ---------------------------------------------------------- anaconda - 10.90.12-1.s390 requires libdevmapper.so.1.01(Base) anaconda - 10.90.12-1.s390 requires libdevmapper.so.1.01 cryptsetup-luks-devel - 1.0.1-3.s390 requires libdevmapper.so.1.01(Base) cryptsetup-luks-devel - 1.0.1-3.s390 requires libdevmapper.so.1.01 device-mapper - 1.02.02-1.s390 requires libdevmapper.so.1.01(Base) device-mapper - 1.02.02-1.s390 requires libdevmapper.so.1.01 device-mapper-multipath - 0.4.4-2.4.s390 requires libdevmapper.so.1.01(Base) device-mapper-multipath - 0.4.4-2.4.s390 requires libdevmapper.so.1.01 evolution - 2.4.1-8.s390 requires libdbus-1.so.1 evolution - 2.4.1-8.s390 requires libdbus-glib-1.so.1 kdesdk - 3.4.92-2.s390 requires libapr-0.so.0 kdesdk - 3.4.92-2.s390 requires libaprutil-0.so.0 kpartx - 0.4.4-2.4.s390 requires libdevmapper.so.1.01(Base) kpartx - 0.4.4-2.4.s390 requires libdevmapper.so.1.01 mod_auth_kerb - 5.0-7.s390 requires httpd-mmn = 0:20020903 mod_auth_mysql - 1:2.9.0-2.s390 requires httpd-mmn = 0:20020903 mod_auth_pgsql - 2.0.1-8.s390 requires httpd-mmn = 0:20020903 mod_authz_ldap - 0.26-4.s390 requires httpd-mmn = 0:20020903 mod_jk - 1.2.6-3jpp_4fc.s390 requires httpd-mmn = 0:20020903 rhythmbox - 0.9.1-1.s390 requires libdbus-1.so.1 rhythmbox - 0.9.1-1.s390 requires libdbus-glib-1.so.1 Broken deps for s390x ---------------------------------------------------------- anaconda - 10.90.12-1.s390x requires libdevmapper.so.1.01()(64bit) anaconda - 10.90.12-1.s390x requires libdevmapper.so.1.01(Base)(64bit) cryptsetup-luks-devel - 1.0.1-3.s390x requires libdevmapper.so.1.01()(64bit) cryptsetup-luks-devel - 1.0.1-3.s390x requires libdevmapper.so.1.01(Base)(64bit) device-mapper - 1.02.02-1.s390 requires libdevmapper.so.1.01(Base) device-mapper - 1.02.02-1.s390 requires libdevmapper.so.1.01 device-mapper - 1.02.02-1.s390x requires libdevmapper.so.1.01()(64bit) device-mapper - 1.02.02-1.s390x requires libdevmapper.so.1.01(Base)(64bit) device-mapper-multipath - 0.4.4-2.4.s390x requires libdevmapper.so.1.01(Base)(64bit) device-mapper-multipath - 0.4.4-2.4.s390x requires libdevmapper.so.1.01()(64bit) evolution - 2.4.1-8.s390x requires libdbus-1.so.1()(64bit) evolution - 2.4.1-8.s390x requires libdbus-glib-1.so.1()(64bit) kdesdk - 3.4.92-2.s390x requires libapr-0.so.0()(64bit) kdesdk - 3.4.92-2.s390x requires libaprutil-0.so.0()(64bit) kpartx - 0.4.4-2.4.s390x requires libdevmapper.so.1.01(Base)(64bit) kpartx - 0.4.4-2.4.s390x requires libdevmapper.so.1.01()(64bit) mod_auth_kerb - 5.0-7.s390x requires httpd-mmn = 0:20020903 mod_auth_mysql - 1:2.9.0-2.s390x requires httpd-mmn = 0:20020903 mod_auth_pgsql - 2.0.1-8.s390x requires httpd-mmn = 0:20020903 mod_authz_ldap - 0.26-4.s390x requires httpd-mmn = 0:20020903 mod_jk - 1.2.6-3jpp_4fc.s390x requires httpd-mmn = 0:20020903 rhythmbox - 0.9.1-1.s390x requires libdbus-1.so.1()(64bit) rhythmbox - 0.9.1-1.s390x requires libdbus-glib-1.so.1()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 anaconda - 10.90.12-1.x86_64 requires libdevmapper.so.1.01()(64bit) anaconda - 10.90.12-1.x86_64 requires libdevmapper.so.1.01(Base)(64bit) cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 cryptsetup-luks-devel - 1.0.1-3.x86_64 requires libdevmapper.so.1.01()(64bit) cryptsetup-luks-devel - 1.0.1-3.x86_64 requires libdevmapper.so.1.01(Base)(64bit) device-mapper - 1.02.02-1.i386 requires libdevmapper.so.1.01(Base) device-mapper - 1.02.02-1.i386 requires libdevmapper.so.1.01 device-mapper - 1.02.02-1.x86_64 requires libdevmapper.so.1.01()(64bit) device-mapper - 1.02.02-1.x86_64 requires libdevmapper.so.1.01(Base)(64bit) device-mapper-multipath - 0.4.4-2.4.x86_64 requires libdevmapper.so.1.01(Base)(64bit) device-mapper-multipath - 0.4.4-2.4.x86_64 requires libdevmapper.so.1.01()(64bit) dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 evolution - 2.4.1-8.x86_64 requires libdbus-1.so.1()(64bit) evolution - 2.4.1-8.x86_64 requires libdbus-glib-1.so.1()(64bit) gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 kdesdk - 3.4.92-2.x86_64 requires libapr-0.so.0()(64bit) kdesdk - 3.4.92-2.x86_64 requires libaprutil-0.so.0()(64bit) kpartx - 0.4.4-2.4.x86_64 requires libdevmapper.so.1.01(Base)(64bit) kpartx - 0.4.4-2.4.x86_64 requires libdevmapper.so.1.01()(64bit) mod_auth_kerb - 5.0-7.x86_64 requires httpd-mmn = 0:20020903 mod_auth_mysql - 1:2.9.0-2.x86_64 requires httpd-mmn = 0:20020903 mod_auth_pgsql - 2.0.1-8.x86_64 requires httpd-mmn = 0:20020903 mod_authz_ldap - 0.26-4.x86_64 requires httpd-mmn = 0:20020903 mod_jk - 1.2.6-3jpp_4fc.x86_64 requires httpd-mmn = 0:20020903 python-pyblock - 0.6-1.x86_64 requires libdevmapper.so.1.01(Base)(64bit) python-pyblock - 0.6-1.x86_64 requires libdevmapper.so.1.01()(64bit) rhythmbox - 0.9.2-2.x86_64 requires libnautilus-burn.so.2()(64bit) From wrrhdev at riede.org Sun Dec 4 14:11:45 2005 From: wrrhdev at riede.org (Willem Riede) Date: Sun, 04 Dec 2005 14:11:45 +0000 Subject: Dovecot 1.0 Message-ID: <1133705505l.3795l.0l@serve.riede.org> Can we have dovecot 1.0 alpha4 in FC5? Even though the word alpha is present in the version, it is quite stable, and fixes many problems that there are in 0.99.14. As a matter of fact, there is no upstream support for 0.99.x. Any reports are met with 'please upgrade and your problem will likely be over'. Take bugs 163550 and 173928 - you can probably just close them after this move :-) I built my own rpm for alpha4, and have it working quite well on FC5test1. Thanks, Willem Riede. From Axel.Thimm at ATrpms.net Sun Dec 4 14:41:44 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sun, 4 Dec 2005 15:41:44 +0100 Subject: Fedora Directory Server in rawhide/FC5? Message-ID: <20051204144144.GA2312@neu.nirvana> Hi, it is too late to have FDS be part of FC5, isn't it? Is anyone working on pushing a package into rawhide anyway? 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 nicolas.mailhot at laposte.net Sun Dec 4 14:45:52 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 04 Dec 2005 15:45:52 +0100 Subject: Fedora Directory Server in rawhide/FC5? In-Reply-To: <20051204144144.GA2312@neu.nirvana> References: <20051204144144.GA2312@neu.nirvana> Message-ID: <1133707558.4122.4.camel@rousalka.dyndns.org> Le dimanche 04 d?cembre 2005 ? 15:41 +0100, Axel Thimm a ?crit : > Hi, > > it is too late to have FDS be part of FC5, isn't it? Is anyone working > on pushing a package into rawhide anyway? Have the SUN jvm bits been cleaned up yet or is it still depending on sun's java plugin ? 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 maxer1 at xmission.com Sun Dec 4 15:44:39 2005 From: maxer1 at xmission.com (RaXeT) Date: Sun, 04 Dec 2005 08:44:39 -0700 Subject: netdev 1644 debugging slowness Message-ID: <43930EE7.2050602@xmission.com> Installed latest netdev 2.6.14-1.1644, and was wondering if there were some grub editing one could do to remove the major debugging enabled in it? My system crawls using netdev. However dropping back to my SysKonnect patched 2.6.14-1.1637_FC5 kernel screams unmercifully. :) RaXeT From dennis at ausil.us Sun Dec 4 16:16:50 2005 From: dennis at ausil.us (Dennis Gilmore) Date: Sun, 4 Dec 2005 10:16:50 -0600 Subject: Fedora Directory Server in rawhide/FC5? In-Reply-To: <1133707558.4122.4.camel@rousalka.dyndns.org> References: <20051204144144.GA2312@neu.nirvana> <1133707558.4122.4.camel@rousalka.dyndns.org> Message-ID: <200512041017.12923.dennis@ausil.us> Once upon a time Sunday 04 December 2005 8:45 am, Nicolas Mailhot wrote: > Le dimanche 04 d?cembre 2005 ? 15:41 +0100, Axel Thimm a ?crit : > > Hi, > > > > it is too late to have FDS be part of FC5, isn't it? Is anyone working > > on pushing a package into rawhide anyway? > > Have the SUN jvm bits been cleaned up yet or is it still depending on > sun's java plugin ? > > Regards, Its not requiring suns jvm in particular but the docs indicate that it needs sun's or IBM's JVM 1.4.2 so it would probably work with blackdown's also. but i dont think it will work with gcc's java yet -- Dennis Gilmore, RHCE http://www.ausil.us -------------- 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 Sun Dec 4 18:12:09 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sun, 4 Dec 2005 19:12:09 +0100 Subject: rawhide report: 20051203 changes In-Reply-To: <4392262A.30500@research.att.com> References: <200512032017.jB3KH2PK009901@porkchop.devel.redhat.com> <4392262A.30500@research.att.com> Message-ID: <20051204191209.383f52ae@nausicaa.camperquake.de> Hi. John Ellson wrote: > # rpm -e dbus-qt > error: Failed dependencies: > libdbus-qt-1.so.1 is needed by (installed) > kdebase-3.5.0-0.1.rc2.i386 I upgraded to current devel 3 hours ago, and the new kdebase pulled in (no version as the machine in question is powered off) did no longer need this. -- Eva: Goddess Diana, fail you I will. / I was to bring you fresh sperm from my Bill. / I had him erect and his semen would follow. / Alas, I was hot. So hot that I swallowed. From denis at poolshark.org Sun Dec 4 19:33:53 2005 From: denis at poolshark.org (Denis Leroy) Date: Sun, 04 Dec 2005 11:33:53 -0800 Subject: rawhide report: 20051204 changes In-Reply-To: <200512041142.jB4Bggwr020404@porkchop.devel.redhat.com> References: <200512041142.jB4Bggwr020404@porkchop.devel.redhat.com> Message-ID: <439344A1.8010405@poolshark.org> Build System wrote: > Broken deps for i386 > ---------------------------------------------------------- > device-mapper - 1.02.02-1.i386 requires libdevmapper.so.1.01(Base) > device-mapper - 1.02.02-1.i386 requires libdevmapper.so.1.01 I filed bug 174946 for this. From pjones at redhat.com Sun Dec 4 19:43:31 2005 From: pjones at redhat.com (Peter Jones) Date: Sun, 04 Dec 2005 14:43:31 -0500 Subject: rawhide report: 20051204 changes In-Reply-To: <439344A1.8010405@poolshark.org> References: <200512041142.jB4Bggwr020404@porkchop.devel.redhat.com> <439344A1.8010405@poolshark.org> Message-ID: <1133725411.26629.4.camel@localhost.localdomain> On Sun, 2005-12-04 at 11:33 -0800, Denis Leroy wrote: > Build System wrote: > > Broken deps for i386 > > ---------------------------------------------------------- > > device-mapper - 1.02.02-1.i386 requires libdevmapper.so.1.01(Base) > > device-mapper - 1.02.02-1.i386 requires libdevmapper.so.1.01 > > > I filed bug 174946 for this. In general, I don't think it's worth filing a bug for the broken deps in the daily report; it already hits everybodys' mailboxes just the same. Oh, and it's fixed now. -- Peter From green at redhat.com Mon Dec 5 00:02:48 2005 From: green at redhat.com (Anthony Green) Date: Sun, 04 Dec 2005 16:02:48 -0800 Subject: Fedora Directory Server in rawhide/FC5? In-Reply-To: <200512041017.12923.dennis@ausil.us> References: <20051204144144.GA2312@neu.nirvana> <1133707558.4122.4.camel@rousalka.dyndns.org> <200512041017.12923.dennis@ausil.us> Message-ID: <1133740968.3036.63.camel@localhost.localdomain> On Sun, 2005-12-04 at 10:16 -0600, Dennis Gilmore wrote: > Its not requiring suns jvm in particular but the docs indicate that it needs > sun's or IBM's JVM 1.4.2 so it would probably work with blackdown's also. > but i dont think it will work with gcc's java yet My understanding is that as of a couple of weeks ago GNU Classpath has all the patches we need to run FDS well (thanks to Lillian Angel). So having FDS run on our free stack in Fedora depends on FC5 moving over to GCC 4.1 and making sure it has Lillian's latest fixes. AG From bernie at develer.com Mon Dec 5 00:18:00 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Mon, 05 Dec 2005 01:18:00 +0100 Subject: Dovecot 1.0 In-Reply-To: <1133705505l.3795l.0l@serve.riede.org> References: <1133705505l.3795l.0l@serve.riede.org> Message-ID: <43938738.3090906@develer.com> Willem Riede wrote: > Can we have dovecot 1.0 alpha4 in FC5? Even though the word alpha is > present in the version, it is quite stable, and fixes many problems that > there are in 0.99.14. As a matter of fact, there is no upstream support > for 0.99.x. Any reports are met with 'please upgrade and your problem > will likely be over'. Yes, please! I was waiting for Dovecot 1.0 to switch to Dovecot from courier-imap without anyone noticing the difference. The feature I'm missing in 0.99 is namespaces. Without this, I'd have to reconfigure all the MUAs to change their IMAP prefix from "INBOX" to "" (empty string). -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From naoki at valuecommerce.com Mon Dec 5 05:09:36 2005 From: naoki at valuecommerce.com (Naoki) Date: Mon, 05 Dec 2005 14:09:36 +0900 Subject: apache 2.2.0 In-Reply-To: <4392C642.6080308@reub.net> References: <1133499537.453.99.camel@dragon.sys.intra> <4392B25B.1040902@feuerpokemon.de> <4392C642.6080308@reub.net> Message-ID: <1133759376.3366.69.camel@dragon.sys.intra> Marvellous! Couple this with FDS just out and it'll be a happy hanukkah! On Sun, 2005-12-04 at 23:34 +1300, Reuben Farrelly wrote: > > On 4/12/2005 10:09 p.m., dragoran wrote: > > Naoki wrote: > > > >> Any chance of this going into FC5? > >> > >> Or has the boat sailed? > >> > >> > >> > > looking at the schedule: > > http://fedora.redhat.com/participate/schedule/ > > the test2 devel freeze is on Dec 19 so there should be enough time to > > get it into test2 (and fc5 final ) > > It's in rawhide now - in case you hadn't noticed...which means it's likely to be > in FC5. > > By all accounts here Apache 2.1 + php 5.1 is good :) > > reuben From gmaxwell at gmail.com Mon Dec 5 06:36:49 2005 From: gmaxwell at gmail.com (Gregory Maxwell) Date: Mon, 5 Dec 2005 01:36:49 -0500 Subject: Mdadm in FC5 Message-ID: I noticed the mdadm in FC5 test 1 is still at 1.11. There have been a number of important advances in raid support in the kernel recently (such as write-intent-bitmaps) which require a new version of mdadm. (can be found at http://www.cse.unsw.edu.au/~neilb/source/mdadm/) Is this a potential for FC5? What work needs to be done to get it integrated? From reuben-fedora-devel at reub.net Mon Dec 5 06:40:02 2005 From: reuben-fedora-devel at reub.net (Reuben Farrelly) Date: Mon, 05 Dec 2005 19:40:02 +1300 Subject: Mdadm in FC5 In-Reply-To: References: Message-ID: <4393E0C2.5060604@reub.net> On 5/12/2005 7:36 p.m., Gregory Maxwell wrote: > I noticed the mdadm in FC5 test 1 is still at 1.11. There have been a > number of important advances in raid support in the kernel recently > (such as write-intent-bitmaps) which require a new version of mdadm. > (can be found at http://www.cse.unsw.edu.au/~neilb/source/mdadm/) > > Is this a potential for FC5? What work needs to be done to get it integrated? https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=167897 reuben From tmus at tmus.dk Mon Dec 5 08:20:09 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Mon, 05 Dec 2005 09:20:09 +0100 Subject: yum plugin suggestion or yum change? Message-ID: Hi, although I find yum to be an excellent tool, there is one important thing that I think needs attention. When updating multiple packages, yum will bail out on dependency error with a singloe package. For the development repo i guess this is *just* annoying, but in a real-life prod style environment, it could mean that security updates are not applied by the nightly scheduled yum update. Giving crackers better time to target the systems. I realize that fixing something like this needs some policies to be negotiated, since often the dependency problems can be solved in multiple ways and we need to figure out how to handle such cases. But wouldn't it be a good idea to try to make yum figure out what packages to exclude in order to update as much as possible? /Thomas From mk at crc.dk Mon Dec 5 09:57:10 2005 From: mk at crc.dk (Mogens Kjaer) Date: Mon, 05 Dec 2005 10:57:10 +0100 Subject: yum plugin suggestion or yum change? In-Reply-To: References: Message-ID: <43940EF6.4000504@crc.dk> Thomas M Steenholdt wrote: ... > When updating multiple packages, yum will bail out on dependency error > with a singloe package. Maybe yum should start over again, trying other mirrors, if dependencies are not satisfied? Mogens -- Mogens Kjaer, Carlsberg A/S, Computer Department Gamle Carlsberg Vej 10, DK-2500 Valby, Denmark Phone: +45 33 27 53 25, Fax: +45 33 27 47 08 Email: mk at crc.dk Homepage: http://www.crc.dk From tmus at tmus.dk Mon Dec 5 10:29:04 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Mon, 05 Dec 2005 11:29:04 +0100 Subject: yum plugin suggestion or yum change? In-Reply-To: <43940EF6.4000504@crc.dk> References: <43940EF6.4000504@crc.dk> Message-ID: Mogens Kjaer wrote: > Thomas M Steenholdt wrote: > ... >> When updating multiple packages, yum will bail out on dependency error >> with a singloe package. > > Maybe yum should start over again, trying other mirrors, > if dependencies are not satisfied? > > Mogens > That would possibly solve some issues, but i think a better way would be something like testing dependencies for each package and ONLY adding it to the transaction list if dependencies can be resolved (slightly simplified description of course). An example from the development tree a few days ago, yum -y update fails to update anything at all because of avahi and a few other things. yum -y update httpd is able to successfully update httpd with all its dependencies including php and others. So in this case httpd (and all the other packages that have no problems) should have the possibility to actually be updated by a simple yum -y update. Yum should simply warn that certain packages cannot be updated and then continue to perform the update of everything else. Some times people add 3rd party repo's that are not always totally sane (could be a local repo with business related packages). But a few problems should not cause other packages from being updated. /Thomas From buildsys at redhat.com Mon Dec 5 11:28:22 2005 From: buildsys at redhat.com (Build System) Date: Mon, 5 Dec 2005 06:28:22 -0500 Subject: rawhide report: 20051205 changes Message-ID: <200512051128.jB5BSM0C031230@porkchop.devel.redhat.com> Updated Packages: anaconda-10.90.12-2 ------------------- * Sun Dec 04 2005 Peter Jones - 10.90.12-2 - rebuild for new libs * Thu Dec 01 2005 Jeremy Katz - 10.90.12-1 - some release notes viewer fixing (dcantrell) - allow %pre scripts in an %include (clumens, #166100) - fix the squashfs stuff to actually work - hack around slang not initializing utf8 mode so that we have line drawing chars (#174761) * Thu Dec 01 2005 Jeremy Katz - 10.90.11-1 - reworded media check prompt (dcantrell, #174472) - let's try squashfs... checkpolicy-1.27.20-1 --------------------- * Sun Dec 04 2005 Dan Walsh 1.27.20-1 - Latest upgrade from NSA * Merged checkmodule man page from Dan Walsh, and edited it. device-mapper-1.02.02-2 ----------------------- * Sat Dec 03 2005 Peter Jones - 1.02.02-2 - fix link path for libdevmapper-event.so * Fri Dec 02 2005 Peter Jones - 1.02.02-1 - update to 1.02.02 * Thu Dec 01 2005 Peter Jones - 1.01.05-4 - add api call to make device nodes explicitly, rather than the previous approach device-mapper-multipath-0.4.4-2.6 --------------------------------- * Sun Dec 04 2005 Peter Jones - 0.4.4-2.6 - rebuild for newer libs * Tue Nov 15 2005 Peter Jones - 0.4.4-2.5 - unsplit kpartx. parted knows how to do this now, so we don't need this in a separate package. dmraid-1.0.0.rc9-FC5_4 ---------------------- * Sat Dec 03 2005 Peter Jones 1.0.0.rc9-FC5_4 - rebuild for device-mapper-1.02.02-2 evolution-2.4.2-2 ----------------- * Fri Dec 02 2005 David Malcolm - 2.4.2-2 - force regeneration of the intltool files to prevent a problem where the tarball copy of intltool-merge.in was out of sync with the intltool.m4 in the latest shipped copy of intltool, which resulted in a broken intltool-merge script when the tree was reautotooled. (appears that the tarball was built with a CVS copy of intltool where @EXPANDED_LIBDIR@ had been renamed to @INTLTOOL_LIBDIR@, but our aclocal/intltool.m4 doesn't yet reflect that change) * Tue Nov 29 2005 David Malcolm - 2.4.2-1 - 2.4.2 - explicitly list the plugins that are packaged (#166234) - added build-time requirement on gstreamer-devel to cope with audio-inline plugin * Tue Nov 29 2005 David Malcolm - 2.4.1-8 - add -DLDAP_DEPRECATED to CFLAGS (#172999) evolution-connector-2.4.2-1 --------------------------- * Fri Dec 02 2005 David Malcolm - 2.4.2-1 - 2.4.2 - regenerate patch 200; forcing regeneration of intltool scripts to keep them in sync with our aclocal/intltool.m4 kdeaddons-3.5.0-1 ----------------- * Tue Nov 29 2005 Than Ngo 3.5.0-1 - 3.5 final kdeedu-3.5.0-1 -------------- * Tue Nov 29 2005 Than Ngo 3.5.0-1 - 3.5 final kdesdk-3.5.0-1 -------------- * Fri Dec 02 2005 Than Ngo 2:3.5.0-1 - 3.5 kdevelop-9:3.3.0-1 ------------------ * Sun Dec 04 2005 Than Ngo 3.3.0-1 - 3.3.0 kdewebdev-6:3.5.0-1 ------------------- * Sun Dec 04 2005 Than Ngo 6:3.5.0-1 - 3.5 libidn-0.6.0-1 -------------- * Sun Dec 04 2005 Joe Orton 0.6.0-1 - update to 0.6.0 php-5.1.1-4 ----------- * Sun Dec 04 2005 Joe Orton 5.1.1-4 - add /usr/share/pear back to hard-coded include_path (#174885) php-pear-1:1.4.5-3 ------------------ policycoreutils-1.27.35-1 ------------------------- * Sun Dec 04 2005 Dan Walsh 1.27.35-1 - Update to match NSA * Merged genhomedircon bug fix from Dan Walsh. * Revised semodule* man pages to refer to checkmodule and to include example sections. * Thu Dec 01 2005 Dan Walsh 1.27.33-1 - Update to match NSA * Merged audit2allow --tefile and --fcfile support from Dan Walsh. * Merged genhomedircon fix from Dan Walsh. * Merged semodule* man pages from Dan Walsh, and edited them. * Changed setfiles to set the MATCHPATHCON_VALIDATE flag to retain validation/canonicalization of contexts during init. * Wed Nov 30 2005 Dan Walsh 1.27.31-1 - Update to match NSA * Changed genhomedircon to always use user_r for the role in the managed case since user_get_defrole is broken. - Add te file capabilities to audit2allow - Add man pages for semodule python-pyblock-0.6-3 -------------------- * Sun Dec 04 2005 Peter Jones - 0.6-3 - rebuild for newer libs * Thu Nov 17 2005 Peter Jones - 0.6-2 - temporarily mask exceptions Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel = 0:2.6.14-1.1696_FC5 cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5smp cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 cryptsetup-luks-devel - 1.0.1-3.i386 requires libdevmapper.so.1.01(Base) cryptsetup-luks-devel - 1.0.1-3.i386 requires libdevmapper.so.1.01 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel = 0:2.6.14-1.1696_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 mod_auth_kerb - 5.0-7.i386 requires httpd-mmn = 0:20020903 mod_auth_mysql - 1:2.9.0-2.i386 requires httpd-mmn = 0:20020903 mod_auth_pgsql - 2.0.1-8.i386 requires httpd-mmn = 0:20020903 mod_authz_ldap - 0.26-4.i386 requires httpd-mmn = 0:20020903 mod_jk - 1.2.6-3jpp_4fc.i386 requires httpd-mmn = 0:20020903 rhythmbox - 0.9.2-2.i386 requires libnautilus-burn.so.2 Broken deps for ia64 ---------------------------------------------------------- cryptsetup-luks-devel - 1.0.1-3.ia64 requires libdevmapper.so.1.01(Base)(64bit) cryptsetup-luks-devel - 1.0.1-3.ia64 requires libdevmapper.so.1.01()(64bit) k3b - 0.12.4-0.a.1.ia64 requires libdbus-qt-1.so.1()(64bit) k3b - 0.12.4-0.a.1.ia64 requires libdbus-1.so.1()(64bit) mod_auth_kerb - 5.0-7.ia64 requires httpd-mmn = 0:20020903 mod_auth_mysql - 1:2.9.0-2.ia64 requires httpd-mmn = 0:20020903 mod_auth_pgsql - 2.0.1-8.ia64 requires httpd-mmn = 0:20020903 mod_authz_ldap - 0.26-4.ia64 requires httpd-mmn = 0:20020903 mod_jk - 1.2.6-3jpp_4fc.ia64 requires httpd-mmn = 0:20020903 rgmanager - 1.9.31-3.ia64 requires ccs rhythmbox - 0.9.2-2.ia64 requires libnautilus-burn.so.2()(64bit) Broken deps for ppc ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 cryptsetup-luks-devel - 1.0.1-3.ppc requires libdevmapper.so.1.01(Base) cryptsetup-luks-devel - 1.0.1-3.ppc requires libdevmapper.so.1.01 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 mod_auth_kerb - 5.0-7.ppc requires httpd-mmn = 0:20020903 mod_auth_mysql - 1:2.9.0-2.ppc requires httpd-mmn = 0:20020903 mod_auth_pgsql - 2.0.1-8.ppc requires httpd-mmn = 0:20020903 mod_authz_ldap - 0.26-4.ppc requires httpd-mmn = 0:20020903 mod_jk - 1.2.6-3jpp_4fc.ppc requires httpd-mmn = 0:20020903 rhythmbox - 0.9.2-2.ppc requires libnautilus-burn.so.2 Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 cryptsetup-luks-devel - 1.0.1-3.ppc64 requires libdevmapper.so.1.01()(64bit) cryptsetup-luks-devel - 1.0.1-3.ppc64 requires libdevmapper.so.1.01(Base)(64bit) dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 k3b - 0.12.4-0.a.1.ppc64 requires libdbus-qt-1.so.1()(64bit) k3b - 0.12.4-0.a.1.ppc64 requires libdbus-1.so.1()(64bit) mod_auth_kerb - 5.0-7.ppc64 requires httpd-mmn = 0:20020903 mod_auth_mysql - 1:2.9.0-2.ppc64 requires httpd-mmn = 0:20020903 mod_auth_pgsql - 2.0.1-8.ppc64 requires httpd-mmn = 0:20020903 mod_authz_ldap - 0.26-4.ppc64 requires httpd-mmn = 0:20020903 mod_jk - 1.2.6-3jpp_4fc.ppc64 requires httpd-mmn = 0:20020903 rhythmbox - 0.9.2-2.ppc64 requires libnautilus-burn.so.2()(64bit) Broken deps for s390 ---------------------------------------------------------- cryptsetup-luks-devel - 1.0.1-3.s390 requires libdevmapper.so.1.01(Base) cryptsetup-luks-devel - 1.0.1-3.s390 requires libdevmapper.so.1.01 mod_auth_kerb - 5.0-7.s390 requires httpd-mmn = 0:20020903 mod_auth_mysql - 1:2.9.0-2.s390 requires httpd-mmn = 0:20020903 mod_auth_pgsql - 2.0.1-8.s390 requires httpd-mmn = 0:20020903 mod_authz_ldap - 0.26-4.s390 requires httpd-mmn = 0:20020903 mod_jk - 1.2.6-3jpp_4fc.s390 requires httpd-mmn = 0:20020903 rhythmbox - 0.9.1-1.s390 requires libdbus-1.so.1 rhythmbox - 0.9.1-1.s390 requires libdbus-glib-1.so.1 Broken deps for s390x ---------------------------------------------------------- cryptsetup-luks-devel - 1.0.1-3.s390x requires libdevmapper.so.1.01()(64bit) cryptsetup-luks-devel - 1.0.1-3.s390x requires libdevmapper.so.1.01(Base)(64bit) mod_auth_kerb - 5.0-7.s390x requires httpd-mmn = 0:20020903 mod_auth_mysql - 1:2.9.0-2.s390x requires httpd-mmn = 0:20020903 mod_auth_pgsql - 2.0.1-8.s390x requires httpd-mmn = 0:20020903 mod_authz_ldap - 0.26-4.s390x requires httpd-mmn = 0:20020903 mod_jk - 1.2.6-3jpp_4fc.s390x requires httpd-mmn = 0:20020903 rhythmbox - 0.9.1-1.s390x requires libdbus-1.so.1()(64bit) rhythmbox - 0.9.1-1.s390x requires libdbus-glib-1.so.1()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 cryptsetup-luks-devel - 1.0.1-3.x86_64 requires libdevmapper.so.1.01()(64bit) cryptsetup-luks-devel - 1.0.1-3.x86_64 requires libdevmapper.so.1.01(Base)(64bit) dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 mod_auth_kerb - 5.0-7.x86_64 requires httpd-mmn = 0:20020903 mod_auth_mysql - 1:2.9.0-2.x86_64 requires httpd-mmn = 0:20020903 mod_auth_pgsql - 2.0.1-8.x86_64 requires httpd-mmn = 0:20020903 mod_authz_ldap - 0.26-4.x86_64 requires httpd-mmn = 0:20020903 mod_jk - 1.2.6-3jpp_4fc.x86_64 requires httpd-mmn = 0:20020903 rhythmbox - 0.9.2-2.x86_64 requires libnautilus-burn.so.2()(64bit) From mattdm at mattdm.org Mon Dec 5 12:56:01 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 5 Dec 2005 07:56:01 -0500 Subject: yum plugin suggestion or yum change? In-Reply-To: References: <43940EF6.4000504@crc.dk> Message-ID: <20051205125601.GA14554@jadzia.bu.edu> On Mon, Dec 05, 2005 at 11:29:04AM +0100, Thomas M Steenholdt wrote: > That would possibly solve some issues, but i think a better way would be > something like testing dependencies for each package and ONLY adding it > to the transaction list if dependencies can be resolved (slightly > simplified description of course). Rather, remove the offending package(s) from the transaction, try again. This idea has been discussed before, and as I understand it, rejected because partial success is often interpretted as "well, that worked", leaving the problem-package ignored. But hey, write a plugin and see what happens! -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From n0dalus+redhat at gmail.com Mon Dec 5 12:59:05 2005 From: n0dalus+redhat at gmail.com (n0dalus) Date: Mon, 5 Dec 2005 23:29:05 +1030 Subject: yum plugin suggestion or yum change? In-Reply-To: <20051205125601.GA14554@jadzia.bu.edu> References: <43940EF6.4000504@crc.dk> <20051205125601.GA14554@jadzia.bu.edu> Message-ID: <6280325c0512050459p75e4c412s3b73bce2561fa9c4@mail.gmail.com> On 12/5/05, Matthew Miller wrote: > > Rather, remove the offending package(s) from the transaction, try again. > > This idea has been discussed before, and as I understand it, rejected > because partial success is often interpretted as "well, that worked", > leaving the problem-package ignored. > > But hey, write a plugin and see what happens! > Can't we just word it in a way that implies something has gone very wrong? n0dalus. From fedora at camperquake.de Mon Dec 5 13:00:52 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 5 Dec 2005 14:00:52 +0100 Subject: yum plugin suggestion or yum change? In-Reply-To: <6280325c0512050459p75e4c412s3b73bce2561fa9c4@mail.gmail.com> References: <43940EF6.4000504@crc.dk> <20051205125601.GA14554@jadzia.bu.edu> <6280325c0512050459p75e4c412s3b73bce2561fa9c4@mail.gmail.com> Message-ID: <20051205130052.GC19731@ryoko.camperquake.de> On Mon, Dec 05, 2005 at 11:29:05PM +1030, n0dalus wrote: > Can't we just word it in a way that implies something has gone very wrong? Or require an additional parameter. yum --partial upgrade From sds at tycho.nsa.gov Mon Dec 5 13:23:52 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 05 Dec 2005 08:23:52 -0500 Subject: udev slowness and selinux In-Reply-To: <4390CFBD.6060305@redhat.com> References: <1133551036.28437.140.camel@moss-spartans.epoch.ncsc.mil> <1133551245.3530.3.camel@rousalka.dyndns.org> <200512021715.28684.czar@czarc.net> <4390CFBD.6060305@redhat.com> Message-ID: <1133789032.20862.20.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2005-12-02 at 17:50 -0500, Daniel J Walsh wrote: > Yesterday's policy package wiped out the policy.20 file, on yum update. > We are no longer shipping policy.20 in the rpm, and the package post > install creates it. Problem is the previous version was shipped with > it and wipes it out on its post uninstall. Need to change the trigger > on policy package to recreate policy.20. > > selinux-policy-*-2.0.7-3 fixes the problem. It is up on my people site > ftp://people.redhat.com/dwalsh/SELinux/Fedora > > You can also do a > semoudle -B /usr/share/selinux/targeted/base.pp to recreate the > policy.20 file. > > Do not reboot until you fix this or else init will crash because you > have no policy. So why is init "crashing" rather than logging a message about the failure to load policy and halting cleanly? Bug in libselinux or in sysvinit-selinux.patch? I moved aside my policy.20 file to prevent loading by init, rebooted with enforcing=0 single, and then ran a trivial program that called the libselinux selinux_init_load_policy() function under valgrind, and it returned -1 as expected without any memory errors being reported, so libselinux seems to handle it correctly. Hence, I would have expected init to log the "Enforcing mode requested but no policy loaded. Halting now." message (from sysvinit-selinux.patch) and then exit normally. -- Stephen Smalley National Security Agency From tmus at tmus.dk Mon Dec 5 13:31:54 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Mon, 05 Dec 2005 14:31:54 +0100 Subject: yum plugin suggestion or yum change? In-Reply-To: <20051205130052.GC19731@ryoko.camperquake.de> References: <43940EF6.4000504@crc.dk> <20051205125601.GA14554@jadzia.bu.edu> <6280325c0512050459p75e4c412s3b73bce2561fa9c4@mail.gmail.com> <20051205130052.GC19731@ryoko.camperquake.de> Message-ID: Ralf Ertzinger wrote: > On Mon, Dec 05, 2005 at 11:29:05PM +1030, n0dalus wrote: > >> Can't we just word it in a way that implies something has gone very wrong? > > Or require an additional parameter. > > yum --partial upgrade > Exactly! In case of system update, partial success is better than no success at all. In most situations, this is probably not true, but here it certainly is. Especially because partial success is actually successful updating of a lot of packages, but with the update of a few packages delayed until such time that their dependencies can be met. There should be no good reason to postpone a security update of apache because of a failed dependency with gaim or whatever. --partial seems to be a good solution to me! /Thomas From sundaram at redhat.com Mon Dec 5 13:38:44 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 05 Dec 2005 19:08:44 +0530 Subject: yum plugin suggestion or yum change? In-Reply-To: References: <43940EF6.4000504@crc.dk> <20051205125601.GA14554@jadzia.bu.edu> <6280325c0512050459p75e4c412s3b73bce2561fa9c4@mail.gmail.com> <20051205130052.GC19731@ryoko.camperquake.de> Message-ID: <439442E4.8010001@redhat.com> Hi > > Exactly! > > In case of system update, partial success is better than no success at > all. In most situations, this is probably not true, but here it > certainly is. > Especially because partial success is actually successful updating of > a lot of packages, but with the update of a few packages delayed until > such time that their dependencies can be met. > There should be no good reason to postpone a security update of apache > because of a failed dependency with gaim or whatever. > > --partial seems to be a good solution to me! This probably should be written as a yum plugin for those working on repositories that can break like development tree. regards Rahul From linux_4ever at yahoo.com Mon Dec 5 13:49:18 2005 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 5 Dec 2005 05:49:18 -0800 (PST) Subject: udev slowness and selinux In-Reply-To: <1133789032.20862.20.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <20051205134918.30390.qmail@web51502.mail.yahoo.com> > Hence, I would have expected init to log the "Enforcing mode > requested but no policy loaded. Halting now." message (from > sysvinit-selinux.patch) and then exit normally. I think for lspp we want it to go to a console prompt where the admin can investigate the problem and make repairs. -Steve __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs From mattdm at mattdm.org Mon Dec 5 13:53:30 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 5 Dec 2005 08:53:30 -0500 Subject: yum plugin suggestion or yum change? In-Reply-To: <439442E4.8010001@redhat.com> References: <43940EF6.4000504@crc.dk> <20051205125601.GA14554@jadzia.bu.edu> <6280325c0512050459p75e4c412s3b73bce2561fa9c4@mail.gmail.com> <20051205130052.GC19731@ryoko.camperquake.de> <439442E4.8010001@redhat.com> Message-ID: <20051205135330.GA16208@jadzia.bu.edu> On Mon, Dec 05, 2005 at 07:08:44PM +0530, Rahul Sundaram wrote: > >--partial seems to be a good solution to me! > This probably should be written as a yum plugin for those working on > repositories that can break like development tree. Or occasionally, Fedora Core updates. :) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From sundaram at redhat.com Mon Dec 5 13:56:53 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 05 Dec 2005 19:26:53 +0530 Subject: yum plugin suggestion or yum change? In-Reply-To: <20051205135330.GA16208@jadzia.bu.edu> References: <43940EF6.4000504@crc.dk> <20051205125601.GA14554@jadzia.bu.edu> <6280325c0512050459p75e4c412s3b73bce2561fa9c4@mail.gmail.com> <20051205130052.GC19731@ryoko.camperquake.de> <439442E4.8010001@redhat.com> <20051205135330.GA16208@jadzia.bu.edu> Message-ID: <43944725.6050000@redhat.com> Matthew Miller wrote: >On Mon, Dec 05, 2005 at 07:08:44PM +0530, Rahul Sundaram wrote: > > >>>--partial seems to be a good solution to me! >>> >>> >>This probably should be written as a yum plugin for those working on >>repositories that can break like development tree. >> >> > >Or occasionally, Fedora Core updates. :) > > > Those are regressions that are far less acceptable than the development tree breakages. Unfortunately the amount of feedback from updates-testing repository is very low to the point that many of the bug reports only start flowing in after the packages have been pushed to the main updates repository. regards Rahul From sds at tycho.nsa.gov Mon Dec 5 14:45:23 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 05 Dec 2005 09:45:23 -0500 Subject: udev slowness and selinux In-Reply-To: <20051205134918.30390.qmail@web51502.mail.yahoo.com> References: <20051205134918.30390.qmail@web51502.mail.yahoo.com> Message-ID: <1133793923.20862.64.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2005-12-05 at 05:49 -0800, Steve G wrote: > > Hence, I would have expected init to log the "Enforcing mode > > requested but no policy loaded. Halting now." message (from > > sysvinit-selinux.patch) and then exit normally. > > I think for lspp we want it to go to a console prompt where the admin can > investigate the problem and make repairs. The admin already has options there: - boot with init=bash to bypass init altogether, or - boot with enforcing=0 single to prevent init from halting if it cannot load policy and only come up single-user. But the proper behavior if policy cannot be loaded and the system is in enforcing mode is to halt. -- Stephen Smalley National Security Agency From jspaleta at gmail.com Mon Dec 5 14:42:42 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 5 Dec 2005 09:42:42 -0500 Subject: yum plugin suggestion or yum change? In-Reply-To: <43944725.6050000@redhat.com> References: <43940EF6.4000504@crc.dk> <20051205125601.GA14554@jadzia.bu.edu> <6280325c0512050459p75e4c412s3b73bce2561fa9c4@mail.gmail.com> <20051205130052.GC19731@ryoko.camperquake.de> <439442E4.8010001@redhat.com> <20051205135330.GA16208@jadzia.bu.edu> <43944725.6050000@redhat.com> Message-ID: <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> On 12/5/05, Rahul Sundaram wrote: >This probably should be written as a yum plugin for those working on >repositories that can break like development tree. and > Those are regressions that are far less acceptable than the development > tree breakages. And yet it frequently happens with the GFS related kernel module packages. Security kernel fixes which go directly into updates-released inevitable cause the GFS and related kernel module packages to be out of sync in updates-released. Sometimes for days at a stretch. I don't think anyone's bothered to file this since the last kernel update(even the people I've seen complaining over the last week because they did an everything install) I think a plugin that targets rawhide or similar perpetually broken repos is a foolhardy goal. Rawhide users should not be cuddled with convience tools that help them ignore errors. It's a rawhide users job to sort out the errors and determine if what they are seeing is worth reporting. The original poster's argument was about relying on automated updates to get security updates, an argument that can't hold for rawhide since rawhide explictly insecure. The argument the original poster made about best security practices with regard to automated updates may hold some weight but I counter it with this. Should automated nightly updates be relied on? Is this something Fedora wants to encourage people to do based on security best practises? I certaintly don't automate updates unless I have tested the update process on a single system. I then have other similiar local systems auto update from a local repository. -jef From sundaram at redhat.com Mon Dec 5 14:43:08 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 05 Dec 2005 20:13:08 +0530 Subject: udev slowness and selinux In-Reply-To: <1133793923.20862.64.camel@moss-spartans.epoch.ncsc.mil> References: <20051205134918.30390.qmail@web51502.mail.yahoo.com> <1133793923.20862.64.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <439451FC.4030500@redhat.com> Stephen Smalley wrote: >On Mon, 2005-12-05 at 05:49 -0800, Steve G wrote: > > >>>Hence, I would have expected init to log the "Enforcing mode >>>requested but no policy loaded. Halting now." message (from >>>sysvinit-selinux.patch) and then exit normally. >>> >>> >>I think for lspp we want it to go to a console prompt where the admin can >>investigate the problem and make repairs. >> >> > >The admin already has options there: >- boot with init=bash to bypass init altogether, or >- boot with enforcing=0 single to prevent init from halting if it cannot >load policy and only come up single-user. > >But the proper behavior if policy cannot be loaded and the system is in >enforcing mode is to halt. > > Wouldnt it be better to continue booting by automatically setting SELinux into permissive or disabled state while throwing out warnings at bootup and in the logs?. regards Rahul From linux_4ever at yahoo.com Mon Dec 5 14:51:45 2005 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 5 Dec 2005 06:51:45 -0800 (PST) Subject: udev slowness and selinux In-Reply-To: <439451FC.4030500@redhat.com> Message-ID: <20051205145145.46217.qmail@web51506.mail.yahoo.com> >>But the proper behavior if policy cannot be loaded and the system is in >>enforcing mode is to halt. >From RBAC-987: FPT_RCV.1.1 After a failure or service discontinuity, the TSF shall enter a maintenance mode where the ability to return the TOE to a secure state is provided The phrasing "shall enter" seems to imply automatically to me. >Wouldnt it be better to continue booting by automatically setting >SELinux into permissive or disabled state while throwing out warnings at >bootup and in the logs? That might be OK if someone could select that failure policy, but that is not what we want in a secure environment. -Steve __________________________________ Start your day with Yahoo! - Make it your home page! http://www.yahoo.com/r/hs From dwalsh at redhat.com Mon Dec 5 14:55:49 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 05 Dec 2005 09:55:49 -0500 Subject: udev slowness and selinux In-Reply-To: <439451FC.4030500@redhat.com> References: <20051205134918.30390.qmail@web51502.mail.yahoo.com> <1133793923.20862.64.camel@moss-spartans.epoch.ncsc.mil> <439451FC.4030500@redhat.com> Message-ID: <439454F5.9010706@redhat.com> Rahul Sundaram wrote: > Stephen Smalley wrote: > >> On Mon, 2005-12-05 at 05:49 -0800, Steve G wrote: >> >> >>>> Hence, I would have expected init to log the "Enforcing mode >>>> requested but no policy loaded. Halting now." message (from >>>> sysvinit-selinux.patch) and then exit normally. >>>> >>> I think for lspp we want it to go to a console prompt where the >>> admin can >>> investigate the problem and make repairs. >>> >> >> The admin already has options there: >> - boot with init=bash to bypass init altogether, or >> - boot with enforcing=0 single to prevent init from halting if it cannot >> load policy and only come up single-user. >> >> But the proper behavior if policy cannot be loaded and the system is in >> enforcing mode is to halt. >> >> > Wouldnt it be better to continue booting by automatically setting > SELinux into permissive or disabled state while throwing out warnings > at bootup and in the logs?. > > regards > Rahul > No because this would break your security. It might be arguable if it should bring it to single user mode though. -- From sundaram at redhat.com Mon Dec 5 14:56:23 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 05 Dec 2005 20:26:23 +0530 Subject: yum plugin suggestion or yum change? In-Reply-To: <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> References: <43940EF6.4000504@crc.dk> <20051205125601.GA14554@jadzia.bu.edu> <6280325c0512050459p75e4c412s3b73bce2561fa9c4@mail.gmail.com> <20051205130052.GC19731@ryoko.camperquake.de> <439442E4.8010001@redhat.com> <20051205135330.GA16208@jadzia.bu.edu> <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> Message-ID: <43945517.7080405@redhat.com> Hi >And yet it frequently happens with the GFS related kernel module >packages. Security kernel fixes which go directly into >updates-released inevitable cause the GFS and related kernel module >packages to be out of sync in updates-released. > > GFS kernel modules not being in sync is not much of a regression. Its a known issue documented to a extend in the release notes. http://fedora.redhat.com/docs/release-notes/fc4/#sn-kernel Similar dependencies are there for the Xen kernel too. Any out of tree kernel modules are only going to get sorted when FESCO comes out with a packaging decision on that or better yet when they get merged upstream. If partial upgrade option doesnt sound good to have an alternative could be a plugin that provides a option to exclude a package and all its dependencies in a repository. Instead of changing the exclude options behavior a new one like excludedeps=gtk2 for example can exclude GTK2 and all it dependencies. You can fiddle around with repoquery and figure this out but this is potentially much easier. regards Rahul From mattdm at mattdm.org Mon Dec 5 14:59:30 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 5 Dec 2005 09:59:30 -0500 Subject: yum plugin suggestion or yum change? In-Reply-To: <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> References: <43940EF6.4000504@crc.dk> <20051205125601.GA14554@jadzia.bu.edu> <6280325c0512050459p75e4c412s3b73bce2561fa9c4@mail.gmail.com> <20051205130052.GC19731@ryoko.camperquake.de> <439442E4.8010001@redhat.com> <20051205135330.GA16208@jadzia.bu.edu> <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> Message-ID: <20051205145930.GA19463@jadzia.bu.edu> On Mon, Dec 05, 2005 at 09:42:42AM -0500, Jeff Spaleta wrote: > And yet it frequently happens with the GFS related kernel module > packages. Security kernel fixes which go directly into External kernel module packages are just plain awkward. I haven't seen a great solution yet. > The argument the original poster made about best security practices > with regard to automated updates may hold some weight but I counter it > with this. Should automated nightly updates be relied on? Is this > something Fedora wants to encourage people to do based on security > best practises? I certaintly don't automate updates unless I have > tested the update process on a single system. I then have other > similiar local systems auto update from a local repository. Based on my experience, automatic updates by default *is* best security practice AND turning disabling that default and conscientiously and regularly applying tested updates by hand is also. Most people aren't going to do the "test first" thing, and those who do can turn off the updates. Otherwise, "install and forget" is the normal practice. Or, "install and have the best intentions of updating, but other things are always going on, because I really have this computer to do my work not fiddle around". Occasionally, things break, but the risk of that is smaller than the risk of security problems and generally the consequences less severe. (Downgrade a package vs. must reinstall the whole machine.) Therefore, getting automated updates to work as smoothly as possible seems a good goal. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From sundaram at redhat.com Mon Dec 5 15:01:11 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 05 Dec 2005 20:31:11 +0530 Subject: udev slowness and selinux In-Reply-To: <439454F5.9010706@redhat.com> References: <20051205134918.30390.qmail@web51502.mail.yahoo.com> <1133793923.20862.64.camel@moss-spartans.epoch.ncsc.mil> <439451FC.4030500@redhat.com> <439454F5.9010706@redhat.com> Message-ID: <43945637.6020206@redhat.com> Hi >>> >> Wouldnt it be better to continue booting by automatically setting >> SELinux into permissive or disabled state while throwing out warnings >> at bootup and in the logs?. >> >> regards >> Rahul >> > No because this would break your security. It might be arguable if it > should bring it to single user mode though. In the sense that a non bootable machine is more secure, yes but providing a path to recovery would be good. If I remember right, the error message didnt indicate the word SELinux and was pretty obscure. It didnt provide any suggestions for recovery either. regards Rahul From jspaleta at gmail.com Mon Dec 5 15:05:22 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 5 Dec 2005 10:05:22 -0500 Subject: yum plugin suggestion or yum change? In-Reply-To: <20051205145930.GA19463@jadzia.bu.edu> References: <43940EF6.4000504@crc.dk> <20051205125601.GA14554@jadzia.bu.edu> <6280325c0512050459p75e4c412s3b73bce2561fa9c4@mail.gmail.com> <20051205130052.GC19731@ryoko.camperquake.de> <439442E4.8010001@redhat.com> <20051205135330.GA16208@jadzia.bu.edu> <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <20051205145930.GA19463@jadzia.bu.edu> Message-ID: <604aa7910512050705y1b3c019dx9d0ff5988f320944@mail.gmail.com> On 12/5/05, Matthew Miller wrote: > Based on my experience, automatic updates by default *is* best security > practice AND turning disabling that default and conscientiously and > regularly applying tested updates by hand is also. What in your vastly superior personal experience says this is the best security practise for Core? > > Most people aren't going to do the "test first" thing, and those who do can > turn off the updates. How about we refrain from making comments about what "most" people will be doing. "Most" people will be doing whatever the default setup is. Right now "most" people don't automate updates at all so this line of discussion is moot. Comments like that can not be backed up with any credible data and are a retorical device that only serves to distort the discussion. > Otherwise, "install and forget" is the normal > practice. I'm not asking for normal practise.. I'm asking for what the best practise for this project to support is. -jef From mattdm at mattdm.org Mon Dec 5 15:16:16 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 5 Dec 2005 10:16:16 -0500 Subject: yum plugin suggestion or yum change? In-Reply-To: <604aa7910512050705y1b3c019dx9d0ff5988f320944@mail.gmail.com> References: <20051205125601.GA14554@jadzia.bu.edu> <6280325c0512050459p75e4c412s3b73bce2561fa9c4@mail.gmail.com> <20051205130052.GC19731@ryoko.camperquake.de> <439442E4.8010001@redhat.com> <20051205135330.GA16208@jadzia.bu.edu> <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <20051205145930.GA19463@jadzia.bu.edu> <604aa7910512050705y1b3c019dx9d0ff5988f320944@mail.gmail.com> Message-ID: <20051205151616.GA20220@jadzia.bu.edu> On Mon, Dec 05, 2005 at 10:05:22AM -0500, Jeff Spaleta wrote: > > Based on my experience, automatic updates by default *is* best security > > practice AND turning disabling that default and conscientiously and > > regularly applying tested updates by hand is also. > What in your vastly superior personal experience says this is the best > security practise for Core? Did I say "vastly superior"? Or are you just expecting that it is? :) It's simple: at BU, RHEL and Fedora Core machines get broken into as a matter of course. BU Linux -- which is based on Fedora Core with some changes and additions -- machines generally don't. Some of that is our general tightening of security options, but FC is much, much better by default than RHL6.1, where we started. These days, the main security difference is: automatic updates on by default. Of BU Linux systems which *are* comprimised, the two main culprits are: weak local user passwords set by untrained admins (which we're working on some things to address) and people who have disabled the automatic updates because they have the best intentions of doing it themselves. > > Most people aren't going to do the "test first" thing, and those who do > > can turn off the updates. > How about we refrain from making comments about what "most" people > will be doing. "Most" people will be doing whatever the default setup > is. Right now "most" people don't automate updates at all so this Exactly. Most people will follow the default, which is: no updates at all. > > Otherwise, "install and forget" is the normal > > practice. > I'm not asking for normal practise.. I'm asking for what the best > practise for this project to support is. I'm not asking for snarky. I'm trying to contribute to the discussion. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From sds at tycho.nsa.gov Mon Dec 5 15:47:49 2005 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 05 Dec 2005 10:47:49 -0500 Subject: udev slowness and selinux In-Reply-To: <439454F5.9010706@redhat.com> References: <20051205134918.30390.qmail@web51502.mail.yahoo.com> <1133793923.20862.64.camel@moss-spartans.epoch.ncsc.mil> <439451FC.4030500@redhat.com> <439454F5.9010706@redhat.com> Message-ID: <1133797669.20862.104.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2005-12-05 at 09:55 -0500, Daniel J Walsh wrote: > No because this would break your security. It might be arguable if it > should bring it to single user mode though. Disagree. You already have the options of booting with init=/bin/bash or booting with enforcing=0 single _if_ the machine is configured to allow setting of boot parameters (which might require a password). Automatically switching to single-user mode would mean that someone could always reach single-user mode by inducing a failure that corrupts the policy (hopefully not possible in the first place, but...). I do agree that the message should be more informative though, and that it should be flushed to the console... -- Stephen Smalley National Security Agency From ihok at hotmail.com Mon Dec 5 15:40:22 2005 From: ihok at hotmail.com (Jack Tanner) Date: Mon, 05 Dec 2005 10:40:22 -0500 Subject: yum plugin suggestion or yum change? In-Reply-To: <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> References: <43940EF6.4000504@crc.dk> <20051205125601.GA14554@jadzia.bu.edu> <6280325c0512050459p75e4c412s3b73bce2561fa9c4@mail.gmail.com> <20051205130052.GC19731@ryoko.camperquake.de> <439442E4.8010001@redhat.com> <20051205135330.GA16208@jadzia.bu.edu> <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > with this. Should automated nightly updates be relied on? Is this > something Fedora wants to encourage people to do based on security > best practises? I certaintly don't automate updates unless I have > tested the update process on a single system. I then have other > similiar local systems auto update from a local repository. Think "Aunt Tillie". She's got one PC, not several. She just wants it to be safe from the baddies on the intraweb. QA of an update at a time, with individual QA of each dependency, is not something she is going to do. The simple desktop use case is to turn on automated nightly updates, and to let power users and sysadmins turn those off at their own risk. "Partial" automated updates do make sense for this scenario. From sundaram at redhat.com Mon Dec 5 15:47:12 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 05 Dec 2005 21:17:12 +0530 Subject: Automatic updates ( WAS: yum plugin suggestion or yum change?) In-Reply-To: <20051205145930.GA19463@jadzia.bu.edu> References: <43940EF6.4000504@crc.dk> <20051205125601.GA14554@jadzia.bu.edu> <6280325c0512050459p75e4c412s3b73bce2561fa9c4@mail.gmail.com> <20051205130052.GC19731@ryoko.camperquake.de> <439442E4.8010001@redhat.com> <20051205135330.GA16208@jadzia.bu.edu> <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <20051205145930.GA19463@jadzia.bu.edu> Message-ID: <43946100.3080407@redhat.com> Hi >Based on my experience, automatic updates by default *is* best security >practice AND turning disabling that default and conscientiously and >regularly applying tested updates by hand is also. > > I tried having a discussion about this in #fedora-devel and was shot down by a few people as crazy nut for suggesting that Anaconda or firstboot provide a option that enables updates by default. The pros and cons http://fedoraproject.org/wiki/AutoUpdates regards Rahul From mattdm at mattdm.org Mon Dec 5 15:47:39 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 5 Dec 2005 10:47:39 -0500 Subject: testing updates-testing [was Re: yum plugin suggestion or yum change?] In-Reply-To: <43944725.6050000@redhat.com> References: <43940EF6.4000504@crc.dk> <20051205125601.GA14554@jadzia.bu.edu> <6280325c0512050459p75e4c412s3b73bce2561fa9c4@mail.gmail.com> <20051205130052.GC19731@ryoko.camperquake.de> <439442E4.8010001@redhat.com> <20051205135330.GA16208@jadzia.bu.edu> <43944725.6050000@redhat.com> Message-ID: <20051205154739.GA22099@jadzia.bu.edu> On Mon, Dec 05, 2005 at 07:26:53PM +0530, Rahul Sundaram wrote: > Those are regressions that are far less acceptable than the development > tree breakages. Unfortunately the amount of feedback from > updates-testing repository is very low to the point that many of the bug > reports only start flowing in after the packages have been pushed to the > main updates repository. Yeah, I know. Here at least, we barely have the resources to test the updates that have made it to the main updates repo. I wish we had more time, but generally we only look at things in updates-testing if they seem particularly interesting for some already-known reason. It might help if packages put in updates-testing were accompanied by posts to the announce list. (I know they do sometimes get messages here or on the test list.) -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jspaleta at gmail.com Mon Dec 5 16:17:46 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 5 Dec 2005 11:17:46 -0500 Subject: yum plugin suggestion or yum change? In-Reply-To: References: <20051205125601.GA14554@jadzia.bu.edu> <6280325c0512050459p75e4c412s3b73bce2561fa9c4@mail.gmail.com> <20051205130052.GC19731@ryoko.camperquake.de> <439442E4.8010001@redhat.com> <20051205135330.GA16208@jadzia.bu.edu> <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> Message-ID: <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> On 12/5/05, Jack Tanner wrote: > Think "Aunt Tillie". She's got one PC, not several. She just wants it to > be safe from the baddies on the intraweb. QA of an update at a time, > with individual QA of each dependency, is not something she is going to > do. The simple desktop use case is to turn on automated nightly updates, > and to let power users and sysadmins turn those off at their own risk. > "Partial" automated updates do make sense for this scenario. What AT wants and what is a best practise for AT's situation are very different things. I understand that people "desire" the ability to have reliable automated updates that require absolutely no interaction with the system. I don't think this project can provide that facility "reliably" for the majority of users. And if it automated updates can't be done reliably, then this project should instead focus on notification of updates and user initiated update pulls. I am not convinced that partial updates are in AT's best interest...even though its desired. Allowing normal people to easily ignore errors will only serve to reduce the amount of error reporting that is occuring about package updates. Letting users ignore errors by default even more so. If partial updates can be accomplished with a click of a button, whatever dialog the AT oriented tool throws up about errors becomes nothing more than a nag dialog to click through. Turning update error dialogs into EULA-like nag windows that AT isn't going to read is not useful nor is it wise. If something unexpected happens AT needs to be told, and needs to be told how to contact people who can help her understand, report and resolve the problem. What if the update that isn't being installed IS a security fix? Since the tools have no ability to distinguish security updates from feature updates, how can it be safe to encourage AT ignore the problems? -jef From dwalsh at redhat.com Mon Dec 5 16:56:12 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 05 Dec 2005 11:56:12 -0500 Subject: udev slowness and selinux In-Reply-To: <1133789032.20862.20.camel@moss-spartans.epoch.ncsc.mil> References: <1133551036.28437.140.camel@moss-spartans.epoch.ncsc.mil> <1133551245.3530.3.camel@rousalka.dyndns.org> <200512021715.28684.czar@czarc.net> <4390CFBD.6060305@redhat.com> <1133789032.20862.20.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4394712C.8020103@redhat.com> Stephen Smalley wrote: > On Fri, 2005-12-02 at 17:50 -0500, Daniel J Walsh wrote: > >> Yesterday's policy package wiped out the policy.20 file, on yum update. >> We are no longer shipping policy.20 in the rpm, and the package post >> install creates it. Problem is the previous version was shipped with >> it and wipes it out on its post uninstall. Need to change the trigger >> on policy package to recreate policy.20. >> >> selinux-policy-*-2.0.7-3 fixes the problem. It is up on my people site >> ftp://people.redhat.com/dwalsh/SELinux/Fedora >> >> You can also do a >> semoudle -B /usr/share/selinux/targeted/base.pp to recreate the >> policy.20 file. >> >> Do not reboot until you fix this or else init will crash because you >> have no policy. >> > > So why is init "crashing" rather than logging a message about the > failure to load policy and halting cleanly? Bug in libselinux or in > sysvinit-selinux.patch? I moved aside my policy.20 file to prevent > loading by init, rebooted with enforcing=0 single, and then ran a > trivial program that called the libselinux selinux_init_load_policy() > function under valgrind, and it returned -1 as expected without any > memory errors being reported, so libselinux seems to handle it > correctly. Hence, I would have expected init to log the "Enforcing mode > requested but no policy loaded. Halting now." message (from > sysvinit-selinux.patch) and then exit normally. > > I think the message is being printed but not being flushed I am putting a fix in init to make sure message comes out. From michael.favia at insitesinc.com Mon Dec 5 17:47:08 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Mon, 05 Dec 2005 11:47:08 -0600 Subject: yum plugin suggestion or yum change? In-Reply-To: <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> References: <20051205125601.GA14554@jadzia.bu.edu> <6280325c0512050459p75e4c412s3b73bce2561fa9c4@mail.gmail.com> <20051205130052.GC19731@ryoko.camperquake.de> <439442E4.8010001@redhat.com> <20051205135330.GA16208@jadzia.bu.edu> <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> Message-ID: <43947D1C.6030704@insitesinc.com> Jeff Spaleta wrote: > On 12/5/05, Jack Tanner wrote: >> Think "Aunt Tillie". She's got one PC, not several. She just wants it to >> be safe from the baddies on the intraweb. QA of an update at a time, >> with individual QA of each dependency, is not something she is going to >> do. The simple desktop use case is to turn on automated nightly updates, >> and to let power users and sysadmins turn those off at their own risk. >> "Partial" automated updates do make sense for this scenario. > > What AT wants and what is a best practise for AT's situation are very > different things. > I understand that people "desire" the ability to have reliable > automated updates that require absolutely no interaction with the > system. I don't think this project can provide that facility > "reliably" for the majority of users. And if it automated updates > can't be done reliably, then this project should instead focus on > notification of updates and user initiated update pulls. > > I am not convinced that partial updates are in AT's best > interest...even though its desired. > Allowing normal people to easily ignore errors will only serve to > reduce the amount of error reporting that is occuring about package > updates. Letting users ignore errors by default even more so. If > partial updates can be accomplished with a click of a button, whatever > dialog the AT oriented tool throws up about errors becomes nothing > more than a nag dialog to click through. Turning update error dialogs > into EULA-like nag windows that AT isn't going to read is not useful > nor is it wise. If something unexpected happens AT needs to be told, > and needs to be told how to contact people who can help her > understand, report and resolve the problem. What if the update that > isn't being installed IS a security fix? Since the tools have no > ability to distinguish security updates from feature updates, how can > it be safe to encourage AT ignore the problems? Because if given the choice to do something confusing or nothing at all AT will do nothing at all (After all her system is working well right now according to her right?). I think this is pretty self evident in her lack of effort or unwillingness to enable auto updates from the beginning. If you want to auto report such hangups as dep resolutions then you might have a solution to your "missing data" assuming the users agree to such a policy. We dont want to force AT to submit bugreports. That really scares aunt tilly away from fedora. I think we need to realize that there is a class of computer users that just want things to work and wont take action when they dont. The best option for these users is to provide them with at least partial updates to do what we can for them in an automated fashion. Not everyone is a computer enthusiast and i dont think we should ask them to become one to run fedora. I'm not saying that this should be silent. AT should know something is wrong and the severity of it should increase with the amount of time that it persists. She knows to take her car into the repair shop if the engine light is on and i think we can manage the same effect on her computer. Aunt tilly is only one class of user and she doent need to be involved in making these types of decisions. -mf From sundaram at redhat.com Mon Dec 5 17:50:13 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 05 Dec 2005 23:20:13 +0530 Subject: yum plugin suggestion or yum change? In-Reply-To: <43947D1C.6030704@insitesinc.com> References: <20051205125601.GA14554@jadzia.bu.edu> <6280325c0512050459p75e4c412s3b73bce2561fa9c4@mail.gmail.com> <20051205130052.GC19731@ryoko.camperquake.de> <439442E4.8010001@redhat.com> <20051205135330.GA16208@jadzia.bu.edu> <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> <43947D1C.6030704@insitesinc.com> Message-ID: <43947DD5.1060207@redhat.com> Hi > > I'm not saying that this should be silent. AT should know something is > wrong and the severity of it should increase with the amount of time > that it persists. She knows to take her car into the repair shop if > the engine light is on and i think we can manage the same effect on > her computer. How exactly should yum increase the severity? yum has no idea whether the packages that are being missed out over any patial update is a important security update or not. regards Rahul From jspaleta at gmail.com Mon Dec 5 18:21:02 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 5 Dec 2005 13:21:02 -0500 Subject: yum plugin suggestion or yum change? In-Reply-To: <43947D1C.6030704@insitesinc.com> References: <20051205130052.GC19731@ryoko.camperquake.de> <439442E4.8010001@redhat.com> <20051205135330.GA16208@jadzia.bu.edu> <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> <43947D1C.6030704@insitesinc.com> Message-ID: <604aa7910512051021q35bd94ai59316ea025c0ab7a@mail.gmail.com> On 12/5/05, Michael Favia wrote: > I think we need to realize that there is a class of computer users that > just want things to work and wont take action when they dont. The best > option for these users is to provide them with at least partial updates > to do what we can for them in an automated fashion. We all want things to "just work". I want my updates to work every single time I ask for updates. I doubt you can define a "class" of rational computer users who desire updates to fail this isn't pathelogical. The desire to see things work isn't the issue. ...what to do when things fail to work as expected..that is the issue. The issue what the best course of action when there is a detectable error. I am still not convinced it is in an average desktop users best interest to allow partial updates with the current updates framework. > Not everyone is a > computer enthusiast and i dont think we should ask them to become one to > run fedora. And yet, "early adopter, enthusiast, developer" is exactly the group the available project description singles out as the target audience. > I'm not saying that this should be silent. AT should know something is > wrong and the severity of it should increase with the amount of time > that it persists. The tools have no way to distinguish or communicate "severity" so there is no way for AT class users to be notified of the severity of the problem. There is no way for users to know that a partial update would fail to install an important security update. In this regard partial updates produce a false sense of security. "Some updates completed, so I must be somewhat safer." is actually a worse situation to because it can be an untrue statement. I don't think I'm going to be able to support automated partial updates in any form aimed at desktop users until the tools understand how to distiguish security updates from non-security updates and know how to communicate that difference to users when there is an update problem that prevents a security update from installing. > She knows to take her car into the repair shop if the > engine light is on and i think we can manage the same effect on her > computer. Bad analogy to prove your point... the car doesn't try to automatically repair itself at night. -jef From tmus at tmus.dk Mon Dec 5 18:45:29 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Mon, 05 Dec 2005 19:45:29 +0100 Subject: yum plugin suggestion or yum change? In-Reply-To: <43947DD5.1060207@redhat.com> References: <20051205125601.GA14554@jadzia.bu.edu> <6280325c0512050459p75e4c412s3b73bce2561fa9c4@mail.gmail.com> <20051205130052.GC19731@ryoko.camperquake.de> <439442E4.8010001@redhat.com> <20051205135330.GA16208@jadzia.bu.edu> <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> <43947D1C.6030704@insitesinc.com> <43947DD5.1060207@redhat.com> Message-ID: Rahul Sundaram wrote: > Hi > >> >> I'm not saying that this should be silent. AT should know something is >> wrong and the severity of it should increase with the amount of time >> that it persists. She knows to take her car into the repair shop if >> the engine light is on and i think we can manage the same effect on >> her computer. > > How exactly should yum increase the severity? yum has no idea whether > the packages that are being missed out over any patial update is a > important security update or not. > > regards > Rahul > I guess that an important point is that one failing security update does not make up for the rest of the equally important security updates not getting installed. If we have 10 security updates and one of these are failing. Wouldn't we be better off installing the 9 that don't have any problems. This is certainly the way I see it. The error should be equally noisy, but whatever can be updated without problems, really should be. I can't think of any reason not to want this. We're not talking about working around any important stability measure. We're talking about letting good updates through. If one update is misbehaving, it's excluded during this run. that's it. /Thomas From mmcgrath at iesabroad.org Mon Dec 5 18:51:07 2005 From: mmcgrath at iesabroad.org (Mike McGrath) Date: Mon, 5 Dec 2005 12:51:07 -0600 Subject: HTTP Load balancer Message-ID: I understand that Apache 2.2 might make it into FC5 (Its currently in test 1). I was wondering if there were any plans beyond that to include an HTTP based load balancer? Perhaps a TCP based balancer? ------------------- Michael P. McGrath Senior Systems Engineer From sundaram at redhat.com Mon Dec 5 19:06:20 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Tue, 06 Dec 2005 00:36:20 +0530 Subject: yum plugin suggestion or yum change? In-Reply-To: References: <20051205125601.GA14554@jadzia.bu.edu> <6280325c0512050459p75e4c412s3b73bce2561fa9c4@mail.gmail.com> <20051205130052.GC19731@ryoko.camperquake.de> <439442E4.8010001@redhat.com> <20051205135330.GA16208@jadzia.bu.edu> <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> <43947D1C.6030704@insitesinc.com> <43947DD5.1060207@redhat.com> Message-ID: <43948FAC.3040701@redhat.com> Hi > > I guess that an important point is that one failing security update > does not make up for the rest of the equally important security > updates not getting installed. I am not leaving out an update is a good idea unless explicitly configured by the user. One way to avoid that is to include severity level in the metadata and let yum decide on the appropriate course of action based on the level of severity. The course of action might be configurable. One of the important strengths of design in Unix like systems has been to do the best when it can and to fail loudly and completely otherwise. Yum is just doing that. If you dont agree with this idea just write a yum plugin to do what you want it do and get it included in yum-utils and we can check out this in practise and see if its worth getting this feature into yum itself. The idea of doing partial updates have come up many times in several mailing lists and the yum developers dont seem to convinced with the idea. Working code and popularity of that code might convince them. My 2 cents. regards Rahul From jspaleta at gmail.com Mon Dec 5 19:11:19 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 5 Dec 2005 14:11:19 -0500 Subject: yum plugin suggestion or yum change? In-Reply-To: References: <439442E4.8010001@redhat.com> <20051205135330.GA16208@jadzia.bu.edu> <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> <43947D1C.6030704@insitesinc.com> <43947DD5.1060207@redhat.com> Message-ID: <604aa7910512051111u4c9dfcdes151961ffc3796f51@mail.gmail.com> On 12/5/05, Thomas M Steenholdt wrote: > I guess that an important point is that one failing security update does > not make up for the rest of the equally important security updates not > getting installed. who says they other updates are security... or that the other updates are equally important? The tools has absolutely no information by which to make any relative judgement at all. > If we have 10 security updates and one of these are failing. Wouldn't we > be better off installing the 9 that don't have any problems. > certainly the way I see it. The error should be equally noisy, but > whatever can be updated without problems, really should be. This leads directly to a false sense of security. 9 updates out of 10, does not mean you are 90% secure. Are you telling me that you are going to spend an equal amount of time following up on the errors from partial updates than you do from an update that fails to happen at all? > > I can't think of any reason not to want this. We're not talking about > working around any important stability measure. We're talking about > letting good updates through. If one update is misbehaving, it's > excluded during this run. that's it. And the next run, and the next run, and the next run..... You are building a system which encourages people to ignore the problem, instead of investigating and resolving the problem. Let me put on my mind-reading helmet that looks into the future... all the way to the year 2000{tm}. "Why should I bother reporting the partial failure, I'm sure other people are using the exact same mix of packages from the exact same mix of repos that I have and have reported the issue... no need for me to spend time figuring this out" "I'm getting 90% of the updates I should be quite safe...I'm sure if it was an important security issue they'd fix it asap no need for me to report it...." -jef"we have absolutely no valid mechanism on the client side to determine if an update is a security update or not...asking tools to make a judgement and and to be more noisy for some failed updates is asking for just more noise"spaleta From ihok at hotmail.com Mon Dec 5 19:47:53 2005 From: ihok at hotmail.com (Jack Tanner) Date: Mon, 05 Dec 2005 14:47:53 -0500 Subject: yum plugin suggestion or yum change? In-Reply-To: <604aa7910512051021q35bd94ai59316ea025c0ab7a@mail.gmail.com> References: <20051205130052.GC19731@ryoko.camperquake.de> <439442E4.8010001@redhat.com> <20051205135330.GA16208@jadzia.bu.edu> <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> <43947D1C.6030704@insitesinc.com> <604aa7910512051021q35bd94ai59316ea025c0ab7a@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > I don't think I'm going to be able to support automated partial > updates in any form aimed at desktop users until the tools understand > how to distiguish security updates from non-security updates and know > how to communicate that difference to users when there is an update > problem that prevents a security update from installing. Can the tools "know" that an update is a security update if the announcement for it is marked [SECURITY] on fedora-announce-list? Does it help if the announcement is wrapped in an RSS feed, like so: http://rss.gmane.org/messages/complete/gmane.linux.redhat.fedora.core.announce >>She knows to take her car into the repair shop if the >>engine light is on and i think we can manage the same effect on her >>computer. > > Bad analogy to prove your point... the car doesn't try to > automatically repair itself at night. It's a great analogy. I'd be mighty grateful if my car tried to repair itself at night, and only turned on "check engine" if the repair failed. From nicolas.mailhot at laposte.net Mon Dec 5 19:33:23 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 05 Dec 2005 20:33:23 +0100 Subject: yum plugin suggestion or yum change? In-Reply-To: <604aa7910512051111u4c9dfcdes151961ffc3796f51@mail.gmail.com> References: <439442E4.8010001@redhat.com> <20051205135330.GA16208@jadzia.bu.edu> <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> <43947D1C.6030704@insitesinc.com> <43947DD5.1060207@redhat.com> <604aa7910512051111u4c9dfcdes151961ffc3796f51@mail.gmail.com> Message-ID: <43949603.9010404@laposte.net> Jeff Spaleta wrote: > Are you telling me that you are going to spend an equal amount of time > following up on the errors from partial updates than you do from an > update that fails to happen at all? The average user will spend the same time ie no time at all. In one case he'll have all updates except problem ones applied. In another he'll have *no* updates applied as soon as one package (redhat-artwork...) blocks. Guess which system will be rooted first. You severely underestimate human natural laziness if you think playing dumb will motivate them to investigate problems for you. -- Nicolas Mailhot From nicolas.mailhot at laposte.net Mon Dec 5 19:28:12 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 05 Dec 2005 20:28:12 +0100 Subject: yum plugin suggestion or yum change? In-Reply-To: <604aa7910512051021q35bd94ai59316ea025c0ab7a@mail.gmail.com> References: <20051205130052.GC19731@ryoko.camperquake.de> <439442E4.8010001@redhat.com> <20051205135330.GA16208@jadzia.bu.edu> <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> <43947D1C.6030704@insitesinc.com> <604aa7910512051021q35bd94ai59316ea025c0ab7a@mail.gmail.com> Message-ID: <439494CC.3010502@laposte.net> Le lundi 05 d?cembre 2005 ? 13:21 -0500, Jeff Spaleta a ?crit : The issue what the best course of action when there is a detectable > error. I am still not convinced it is in an average desktop users best > interest to allow partial updates with the current updates framework. > If you make the tool behave pathologically in every case users will just stop using it. It's as simple as that, and why ten very secure passwords are much worse than a simple password the user can actually remember without writing it on his desk. You and the others ? stop at the first problem ? advocates are trying to strong-arm users in perfect behaviour. Guess what ? It doesn't work in real life and it won't work for you either. If you really want to protect against persistant update failures make yum collect stats and warn when a package repeatedly fail updates. Do not bother the user with every transient mirror sync hic-cup problem or he'll just start ignoring you altogether. Do you know why windows security sucks ? It's not because the patches does not exist, it's just that applying them has historically been so painful people do not bother. Why are you purposefully making yum use painful as well ? -- Nicolas Mailhot From mattdm at mattdm.org Mon Dec 5 20:19:56 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 5 Dec 2005 15:19:56 -0500 Subject: yum plugin suggestion or yum change? In-Reply-To: References: <439442E4.8010001@redhat.com> <20051205135330.GA16208@jadzia.bu.edu> <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> <43947D1C.6030704@insitesinc.com> <604aa7910512051021q35bd94ai59316ea025c0ab7a@mail.gmail.com> Message-ID: <20051205201956.GA32525@jadzia.bu.edu> On Mon, Dec 05, 2005 at 02:47:53PM -0500, Jack Tanner wrote: > Can the tools "know" that an update is a security update if the > announcement for it is marked [SECURITY] on fedora-announce-list? Does > it help if the announcement is wrapped in an RSS feed, like so: > http://rss.gmane.org/messages/complete/gmane.linux.redhat.fedora.core.announce Not yet they can't. There's some work into including this sort of metadata into some yum plugins, but I think it's some way off before we can be sure of relying on it. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jspaleta at gmail.com Mon Dec 5 20:43:46 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 5 Dec 2005 15:43:46 -0500 Subject: yum plugin suggestion or yum change? In-Reply-To: <439494CC.3010502@laposte.net> References: <439442E4.8010001@redhat.com> <20051205135330.GA16208@jadzia.bu.edu> <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> <43947D1C.6030704@insitesinc.com> <604aa7910512051021q35bd94ai59316ea025c0ab7a@mail.gmail.com> <439494CC.3010502@laposte.net> Message-ID: <604aa7910512051243g66f1394cg5e805f91daea620b@mail.gmail.com> On 12/5/05, Nicolas Mailhot wrote: > Do you know why windows security sucks ? It's not because the patches > does not exist, it's just that applying them has historically been so > painful people do not bother. Why are you purposefully making yum use > painful as well ? I'm really not sure why you decided to through this in...but I'll bite. Yes or no... does Microsoft's XP auto updater understands the difference between critical and non-critical updates and does it offer all available updates as part of automated facility? Does MS's updater allow some critical updates to fail? -jef From dhollis at davehollis.com Mon Dec 5 21:05:25 2005 From: dhollis at davehollis.com (David Hollis) Date: Mon, 05 Dec 2005 16:05:25 -0500 Subject: HTTP Load balancer In-Reply-To: References: Message-ID: <1133816725.4459.26.camel@dhollis-lnx.sunera.com> On Mon, 2005-12-05 at 12:51 -0600, Mike McGrath wrote: > I understand that Apache 2.2 might make it into FC5 (Its currently in > test 1). I was wondering if there were any plans beyond that to include > an HTTP based load balancer? Perhaps a TCP based balancer? > yum install ipvsadm http://www.linuxvirtualserver.org/ Gives you IP load balancing. If you want to get something at Layer 5-7 or so, you might need to use Apache in a reverse proxy type of role or so. There are probably some other things out there as well to handle that level of sophistication. But IPVS is in the box. -- David Hollis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tmus at tmus.dk Mon Dec 5 21:04:17 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Mon, 05 Dec 2005 22:04:17 +0100 Subject: yum plugin suggestion or yum change? In-Reply-To: <43949603.9010404@laposte.net> References: <439442E4.8010001@redhat.com> <20051205135330.GA16208@jadzia.bu.edu> <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> <43947D1C.6030704@insitesinc.com> <43947DD5.1060207@redhat.com> <604aa7910512051111u4c9dfcdes151961ffc3796f51@mail.gmail.com> <43949603.9010404@laposte.net> Message-ID: Nicolas Mailhot wrote: > Jeff Spaleta wrote: > >> Are you telling me that you are going to spend an equal amount of time >> following up on the errors from partial updates than you do from an >> update that fails to happen at all? > > The average user will spend the same time ie no time at all. > In one case he'll have all updates except problem ones applied. > In another he'll have *no* updates applied as soon as one package > (redhat-artwork...) blocks. > > Guess which system will be rooted first. > > You severely underestimate human natural laziness if you think playing > dumb will motivate them to investigate problems for you. > This is exactly the point! /Thomas From tmus at tmus.dk Mon Dec 5 21:24:28 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Mon, 05 Dec 2005 22:24:28 +0100 Subject: yum plugin suggestion or yum change? In-Reply-To: <604aa7910512051111u4c9dfcdes151961ffc3796f51@mail.gmail.com> References: <439442E4.8010001@redhat.com> <20051205135330.GA16208@jadzia.bu.edu> <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> <43947D1C.6030704@insitesinc.com> <43947DD5.1060207@redhat.com> <604aa7910512051111u4c9dfcdes151961ffc3796f51@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > On 12/5/05, Thomas M Steenholdt wrote: >> I guess that an important point is that one failing security update does >> not make up for the rest of the equally important security updates not >> getting installed. > > who says they other updates are security... or that the other updates > are equally important? The tools has absolutely no information by > which to make any relative judgement at all. > Why does it matter. There is absolutely NO reason to stop well-behaving packages from being updated just because of one bad one (not fully synced mirror or whatever). Regardless which package may or may not be a high severity security update. It doesn't matter. If a high severity security patch fails with dependency problems, it's not going to install either way, but we should not interpret that as "Hmm, dependencies for this important update cannot be resolved. Lets ignore ALL security updates until that has been fixed". It's just not the best way security wise. I'd rather have 1 known security hole that I've been warned cannot be installed, than 35 (where the 34 are actually totally updatable if I do them my hand). > >> If we have 10 security updates and one of these are failing. Wouldn't we >> be better off installing the 9 that don't have any problems. >> certainly the way I see it. The error should be equally noisy, but >> whatever can be updated without problems, really should be. > > This leads directly to a false sense of security. > 9 updates out of 10, does not mean you are 90% secure. You're right - But is does mean that your cracker will have to work a little harder to find the right exploit. No reason to make things too easy for him! > > Are you telling me that you are going to spend an equal amount of time > following up on the errors from partial updates than you do from an > update that fails to happen at all? Yup! I'll get the same warning message in my log, but I'll only have to worry about the update that actually has a problem. Not all the other potentially critical updates (again - severity is really not important here - if an update will install, there's NO reason for NOT applying that update). > >> I can't think of any reason not to want this. We're not talking about >> working around any important stability measure. We're talking about >> letting good updates through. If one update is misbehaving, it's >> excluded during this run. that's it. > > And the next run, and the next run, and the next run..... > You are building a system which encourages people to ignore the > problem, instead of investigating and resolving the problem. Let me > put on my mind-reading helmet that looks into the future... all the > way to the year 2000{tm}. This is no different than the current state. Currently, people that do not monitor their logs, will ignore ALL updates. The rest of us, powerusers, sysadmins, developers will report just like we do now. No change here - Only safer systems. > > "Why should I bother reporting the partial failure, I'm sure other > people are using the exact same mix of packages from the exact same > mix of repos that I have and have reported the issue... no need for me > to spend time figuring this out" > > "I'm getting 90% of the updates I should be quite safe...I'm sure if > it was an important security issue they'd fix it asap no need for me > to report it...." If you think this is ANY different from what's going on now, you need to wake up! This IS what a lot of people are doing already - Again, they are missing ALL updates instead of just the ones with unresolved dependencies. > > -jef"we have absolutely no valid mechanism on the client side to > determine if an update is a security update or not...asking tools to > make a judgement and and to be more noisy for some failed updates is > asking for just more noise"spaleta > We don't need this! (for this particular issue, anyway) /Thomas From mattdm at mattdm.org Mon Dec 5 21:41:51 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Mon, 5 Dec 2005 16:41:51 -0500 Subject: yum plugin suggestion or yum change? In-Reply-To: References: <20051205135330.GA16208@jadzia.bu.edu> <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> <43947D1C.6030704@insitesinc.com> <43947DD5.1060207@redhat.com> <604aa7910512051111u4c9dfcdes151961ffc3796f51@mail.gmail.com> Message-ID: <20051205214151.GA3689@jadzia.bu.edu> On Mon, Dec 05, 2005 at 10:24:28PM +0100, Thomas M Steenholdt wrote: > Why does it matter. There is absolutely NO reason to stop well-behaving > packages from being updated just because of one bad one (not fully > synced mirror or whatever). Regardless which package may or may not be a Okay, sounds good. I'll be happy to help test your plugin. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From d.jacobfeuerborn at conversis.de Mon Dec 5 21:56:28 2005 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Mon, 05 Dec 2005 22:56:28 +0100 Subject: Yum bug? Message-ID: <4394B78C.6050009@conversis.de> After cleaning up with "yum clean all" I get the following error when I try to do a "yum check-update": Setting up repositories Cannot open/read repomd.xml file for repository: development Cannot find repomd.xml file for development Error: Cannot find repomd.xml file for development Not sure if I should file a bug or if I'm doing something wrong on my end? Regards, Dennis From jspaleta at gmail.com Mon Dec 5 22:00:36 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 5 Dec 2005 17:00:36 -0500 Subject: Yum bug? In-Reply-To: <4394B78C.6050009@conversis.de> References: <4394B78C.6050009@conversis.de> Message-ID: <604aa7910512051400g741b73fejfb18ab73a811a350@mail.gmail.com> On 12/5/05, Dennis Jacobfeuerborn wrote: > Not sure if I should file a bug or if I'm doing something wrong on my end? bug already reported to the lists repeatedly, and reported in bugzilla and the fix should be in rawhide "soon" since the fc4 test update that fixes this already exists. work-around for now remove all the files named "cachecookie" in your /var/cache/yum tree or wait 8 hours for the cookies to expire. -jef From sundaram at redhat.com Mon Dec 5 22:00:43 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Tue, 06 Dec 2005 03:30:43 +0530 Subject: Yum bug? In-Reply-To: <4394B78C.6050009@conversis.de> References: <4394B78C.6050009@conversis.de> Message-ID: <4394B88B.3030109@redhat.com> Dennis Jacobfeuerborn wrote: > After cleaning up with "yum clean all" I get the following error when > I try to do a "yum check-update": > > Setting up repositories > Cannot open/read repomd.xml file for repository: development > Cannot find repomd.xml file for development > Error: Cannot find repomd.xml file for development > > Not sure if I should file a bug or if I'm doing something wrong on my > end? Known issue. Bug report already filed. Discussed before here and fedora-test list before including a workaround. Look at the archives. regards Rahul From bojan at rexursive.com Mon Dec 5 22:13:58 2005 From: bojan at rexursive.com (Bojan Smojver) Date: Tue, 06 Dec 2005 09:13:58 +1100 Subject: libapreq2 rebuild Message-ID: <20051206091358.vhtui458eoc4w4w4@imp.rexursive.com> Quoting Ville Skytt? : > I'm working on it, but it's bitten by #136009 and #174924; will wait for > comments/resolutions to those first. Yeah, I had issues of similar nature in mod_spin as well. It seems that when you're shipping a library with your own piece of software, the RPATHs get encoded (sometimes as build directories, sometimes as standard paths) and the build fails. So, I'm doing some ugly sed-ing in my Makefile.am to get rid of that: http://www.rexursive.com/svn/mod_spin/trunk/src/Makefile.am -- Bojan From nicolas.mailhot at laposte.net Mon Dec 5 22:15:05 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 05 Dec 2005 23:15:05 +0100 Subject: yum plugin suggestion or yum change? In-Reply-To: <604aa7910512051243g66f1394cg5e805f91daea620b@mail.gmail.com> References: <439442E4.8010001@redhat.com> <20051205135330.GA16208@jadzia.bu.edu> <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> <43947D1C.6030704@insitesinc.com> <604aa7910512051021q35bd94ai59316ea025c0ab7a@mail.gmail.com> <439494CC.3010502@laposte.net> <604aa7910512051243g66f1394cg5e805f91daea620b@mail.gmail.com> Message-ID: <4394BBE9.6010009@laposte.net> Jeff Spaleta wrote: > On 12/5/05, Nicolas Mailhot wrote: >> Do you know why windows security sucks ? It's not because the patches >> does not exist, it's just that applying them has historically been so >> painful people do not bother. Why are you purposefully making yum use >> painful as well ? > > I'm really not sure why you decided to through this in...but I'll > bite. Yes or no... does Microsoft's XP auto updater understands the > difference between critical and non-critical updates and does it offer > all available updates as part of automated facility? > > Does MS's updater allow some critical updates to fail? The microsoft updates follow two modes : A fully automated B separate fixes with long explanations and detailed procedures A sometimes makes mistakes but everyone uses it. That's what yum should be B is akin to the mode you'd like people to follow when yum fails. It was MS default system for years because they didn't trust automation. And almost no one was using it because most people prefer an insecure system to one which forces them to 'investigate" problems manually all the time. Now MS force-feeds updates to everyone even if they sometimes fail, because the end result is orders of magnitudes more secure than not automating fully and expecting people to clean up manually afterwards. ? Le mieux est l'ennemi du bien ? as we say in French. Meaning if you always strive for perfection, you'll never achieve good enough state. Most of the times "good enough" is the right goal. On paper people investing manually every update problem is the best solution. In the actual world they won't investigate no matter what, so by striving for perfect security you're only achieving the reverse. -- Nicolas Mailhot From bojan at rexursive.com Mon Dec 5 22:16:07 2005 From: bojan at rexursive.com (Bojan Smojver) Date: Tue, 06 Dec 2005 09:16:07 +1100 Subject: libapreq2 rebuild In-Reply-To: <20051206091358.vhtui458eoc4w4w4@imp.rexursive.com> References: <20051206091358.vhtui458eoc4w4w4@imp.rexursive.com> Message-ID: <20051206091607.kiyo0uoblwow0ogo@imp.rexursive.com> Quoting Bojan Smojver : > Yeah, I had issues of similar nature in mod_spin as well. [snip] Sorry, sent to the wrong list :-( -- Bojan From jspaleta at gmail.com Mon Dec 5 22:20:26 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 5 Dec 2005 17:20:26 -0500 Subject: yum plugin suggestion or yum change? In-Reply-To: <4394BBE9.6010009@laposte.net> References: <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> <43947D1C.6030704@insitesinc.com> <604aa7910512051021q35bd94ai59316ea025c0ab7a@mail.gmail.com> <439494CC.3010502@laposte.net> <604aa7910512051243g66f1394cg5e805f91daea620b@mail.gmail.com> <4394BBE9.6010009@laposte.net> Message-ID: <604aa7910512051420s4a6e1c11o1065d400adcd4612@mail.gmail.com> On 12/5/05, Nicolas Mailhot wrote: > A fully automated Are you sure about that? I could have sworn that MS categorizes updates into shades and delibrately holds back some available updates where are non-critical(non-security) from the automatic process. -jef From josh at bluga.net Mon Dec 5 22:28:42 2005 From: josh at bluga.net (Joshua Eichorn) Date: Mon, 05 Dec 2005 15:28:42 -0700 Subject: yum plugin suggestion or yum change? In-Reply-To: <604aa7910512051420s4a6e1c11o1065d400adcd4612@mail.gmail.com> References: <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> <43947D1C.6030704@insitesinc.com> <604aa7910512051021q35bd94ai59316ea025c0ab7a@mail.gmail.com> <439494CC.3010502@laposte.net> <604aa7910512051243g66f1394cg5e805f91daea620b@mail.gmail.com> <4394BBE9.6010009@laposte.net> <604aa7910512051420s4a6e1c11o1065d400adcd4612@mail.gmail.com> Message-ID: <4394BF1A.9010208@bluga.net> Jeff Spaleta wrote: >On 12/5/05, Nicolas Mailhot wrote: > > >>A fully automated >> >> > >Are you sure about that? I could have sworn that MS categorizes >updates into shades and delibrately holds back some available updates >where are non-critical(non-security) from the automatic process. > >-jef > > > They have high-priority updates and optional updates. High priority updates get installed by automatic updates, optional have to updated by hand from windows update. most security fixes are High-Priority No major upgrades are, ie the new version of windows media player or the .net framework won't be updated automatically. Of course there are also service packs in the mix, which are forced upgrades at some point since new security fixes are only available if you install them. -josh From josh at bluga.net Mon Dec 5 22:30:27 2005 From: josh at bluga.net (Joshua Eichorn) Date: Mon, 05 Dec 2005 15:30:27 -0700 Subject: yum plugin suggestion or yum change? In-Reply-To: <4394BF1A.9010208@bluga.net> References: <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> <43947D1C.6030704@insitesinc.com> <604aa7910512051021q35bd94ai59316ea025c0ab7a@mail.gmail.com> <439494CC.3010502@laposte.net> <604aa7910512051243g66f1394cg5e805f91daea620b@mail.gmail.com> <4394BBE9.6010009@laposte.net> <604aa7910512051420s4a6e1c11o1065d400adcd4612@mail.gmail.com> <4394BF1A.9010208@bluga.net> Message-ID: <4394BF83.9070302@bluga.net> You might also find the Windows Update FAQ informative: I'll past it here since i'm pretty sure you need IE to view it. FAQ *What is Windows Update?* A Microsoft Web site that provides updates for Windows operating system software and Windows-based hardware. Updates address known issues and help protect against known security threats. Tip: * If you turn on Automatic Updates, Windows Update can deliver high priority updates to your computer as they become available. You can decide when and how updates are installed. *How does it work?* When you visit the Web site, Windows Update scans your computer and tells you which updates apply to your software and hardware. You choose the updates that you want to install and how to install them. *What types of updates can I get?* Microsoft releases many types of updates that address a broad range of issues. To make it easier for you to get the most important updates?updates that help protect your computer and your information?Windows Update uses these categories: * *High priority* Critical updates, security updates, service packs, and update rollups that should be installed as soon as they become available and before you install any other updates. * *Software (optional)* Non-critical fixes for Windows programs, such as Windows Media? Player and Windows Journal Viewer 1.5. * *Hardware (optional)* Non-critical fixes for drivers and other hardware devices, such as video cards, sound cards, scanners, printers, and cameras. *What?s the difference between Express and Custom?* * *Express (recommended)* displays all high priority updates for your computer so that you can install them with one click. This is the quickest and easiest way to keep your computer up to date. * *Custom* displays high priority and optional updates for your computer. You review and select the updates that you want to install, one by one. *Do I need to install optional updates?* No. Optional updates address minor issues or add non-critical functionality to your computer. It is more important to install high priority updates so that your computer gets the latest critical and security-related software. *Can I get updates automatically?* Yes, if you turn on *Automatic Updates*. Windows will check for the latest high priority updates for your computer and install them according to your Automatic Updates setting. *Is Automatic Updates the same as Windows Update?* Yes, but Automatic Updates delivers only high priority updates. To get optional updates, you still need to visit the Windows Update Web site. *What is Automatic Updates?* It?s a feature that works with Windows Update to deliver critical and security-related updates as they become available. When you turn on Automatic Updates (recommended), Windows automatically looks for high priority updates for your computer. You decide how and when the updates are installed. *How can I get more information about an update before I install it?* Click the name of each update to view its description. To view system requirements and support information, click the *Details* link provided in each description. *Do I have to do anything to install an update?* Sometimes. Some updates require you to accept an End User License Agreement (EULA), answer a question about the installation process, or restart your computer before you can install them. *What happens if I select "Don't show me this update again"?* Windows Update will no longer ask you to review or install that update. However, if you hide a high priority update, you might be reminded that you?re missing an update that is critical to the security of your computer. *If I hide an update, how do I get it back later?* On the Windows Update Web site, click *Restore hidden updates*, and then review and install the updates that you want. *How often does Windows Update release new updates?* Security-related updates are released once a month. However, if a security threat occurs, such as a widespread virus or worm that affects Windows-based computers, Microsoft will release a corresponding update as soon as possible. Other types of updates are released whenever they are ready. It?s a good idea to turn on Automatic Updates so that your computer can receive high priority updates as they become available. From nicolas.mailhot at laposte.net Mon Dec 5 22:43:47 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Mon, 05 Dec 2005 23:43:47 +0100 Subject: yum plugin suggestion or yum change? In-Reply-To: <604aa7910512051420s4a6e1c11o1065d400adcd4612@mail.gmail.com> References: <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> <43947D1C.6030704@insitesinc.com> <604aa7910512051021q35bd94ai59316ea025c0ab7a@mail.gmail.com> <439494CC.3010502@laposte.net> <604aa7910512051243g66f1394cg5e805f91daea620b@mail.gmail.com> <4394BBE9.6010009@laposte.net> <604aa7910512051420s4a6e1c11o1065d400adcd4612@mail.gmail.com> Message-ID: <4394C2A3.1090602@laposte.net> Jeff Spaleta wrote: > On 12/5/05, Nicolas Mailhot wrote: >> A fully automated > > Are you sure about that? I could have sworn that MS categorizes > updates into shades and delibrately holds back some available updates > where are non-critical(non-security) from the automatic process. MS reasons for holding back some stuff are not applicable to Fedora. Fedora userbase is not segmented between legitimate users (which can get full updates by going through a portal) and freeloaders (which MS would dearly love to leave in the dust, but can not for PR reasons). If you really worry about missed critical updates make partial updating a repo parameter, separate critical updates from other stuff and set partial=false for the critical update channel. I contend you'll get the same results by simply counting how many times a package fails updating and warning when it gets over some threshold, but if having one repo where yum balks at the first problem makes you happier, you can do it this way too. -- Nicolas Mailhot From wcooley at nakedape.cc Mon Dec 5 22:54:49 2005 From: wcooley at nakedape.cc (Wil Cooley) Date: Mon, 05 Dec 2005 14:54:49 -0800 Subject: HTTP Load balancer In-Reply-To: References: Message-ID: <1133823289.17952.40.camel@willow.odshp.com> On Mon, 2005-12-05 at 12:51 -0600, Mike McGrath wrote: > I understand that Apache 2.2 might make it into FC5 (Its currently in > test 1). I was wondering if there were any plans beyond that to include > an HTTP based load balancer? Perhaps a TCP based balancer? I have a somewhat dated SRPM of Pound: http://ftp.nakedape.cc/nakedape/rhel3/srpm/pound/ (I have a separate build on my IPCop firewall which is more current.) Wil -- Wil Cooley Naked Ape Consulting, Ltd -------------- 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 Mon Dec 5 23:16:09 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 5 Dec 2005 18:16:09 -0500 Subject: yum plugin suggestion or yum change? In-Reply-To: <4394C2A3.1090602@laposte.net> References: <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> <43947D1C.6030704@insitesinc.com> <604aa7910512051021q35bd94ai59316ea025c0ab7a@mail.gmail.com> <439494CC.3010502@laposte.net> <604aa7910512051243g66f1394cg5e805f91daea620b@mail.gmail.com> <4394BBE9.6010009@laposte.net> <604aa7910512051420s4a6e1c11o1065d400adcd4612@mail.gmail.com> <4394C2A3.1090602@laposte.net> Message-ID: <604aa7910512051516g743f5139v56e04289a64812f@mail.gmail.com> On 12/5/05, Nicolas Mailhot wrote: > Jeff Spaleta wrote: > MS reasons for holding back some stuff are not applicable to Fedora. > Fedora userbase is not segmented between legitimate users (which can get > full updates by going through a portal) and freeloaders (which MS would > dearly love to leave in the dust, but can not for PR reasons). I make no claim as to why MS does anything... you brought up MS not me. But I thank you for the lesson in conspiracy theory. > If you really worry about missed critical updates make partial updating > a repo parameter, separate critical updates from other stuff and set > partial=false for the critical update channel. Isn't missed security updates... the underlying concern for everyone in this discussion? This per-repo trick would only work if security updates are actually housed in a seperate repo than non-security updates. That doesn't really work at all with the current repo structure. > I contend you'll get the same results by simply counting how many times > a package fails updating and warning when it gets over some threshold, > but if having one repo where yum balks at the first problem makes you > happier, you can do it this way too. No, not really. I'm not really excited about tools taking a week to notify users of update failures. This whole discussion has been prompted about getting updates asap. Waiting a week to notify a user about a broken critically important security fix.. seeks counter to everyone's desire. It is my contention that reliable auto-updates must make a distinction about security/non-security failures and clearly notify the user asap about security update failures so the user can assess what actions to take. I'm not in favor of encouraging any automated update installation that does not attempt to account for the known security rating when informing the user as to update failures. What I want is the best practise for security updates that can be implemented for the project. If non-interactive partial updates are to be encouraged I want there to be a clear way for the client tools to tell users if any security updates failed. I don't want the security update failure buried indistinquishably in a log of 300 other non-security failures. By my count there have been 354 different update annoucement emails for FC 4 updates since July 7th (when the new update annoucement stuff went live). 69 of those have been tagged as security... 20% or so. How many reported problems with updating in that time have been from security updates as compared to problems with non-security updates? If someone were to do an everything install of Core on any given day and partial autoupdating was encouraged. Which security updates would be held back? Which non-security updates would be held back? Today at the very least, the kernel would be held back due to the GFS packages. I feel that users who rely on auto-updating for security would get a false sense of security by auto-updating without there being a notifcation mechanism to clearly notify the user of unapplied security updates asap. I believe that a false sense of security can be more dangerous than actual insecurity because a false sense of security will embolden some people to take risks they otherwise would not if they knew their were vulnerable. Feel free to disagree. -jef From nicolas.mailhot at laposte.net Mon Dec 5 23:49:29 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 06 Dec 2005 00:49:29 +0100 Subject: yum plugin suggestion or yum change? In-Reply-To: <604aa7910512051516g743f5139v56e04289a64812f@mail.gmail.com> References: <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> <43947D1C.6030704@insitesinc.com> <604aa7910512051021q35bd94ai59316ea025c0ab7a@mail.gmail.com> <439494CC.3010502@laposte.net> <604aa7910512051243g66f1394cg5e805f91daea620b@mail.gmail.com> <4394BBE9.6010009@laposte.net> <604aa7910512051420s4a6e1c11o1065d400adcd4612@mail.gmail.com> <4394C2A3.1090602@laposte.net> <604aa7910512051516g743f5139v56e04289a64812f@mail.gmail.com> Message-ID: <4394D209.1090902@laposte.net> Jeff Spaleta wrote: > On 12/5/05, Nicolas Mailhot wrote: >> Jeff Spaleta wrote: >> MS reasons for holding back some stuff are not applicable to Fedora. >> Fedora userbase is not segmented between legitimate users (which can get >> full updates by going through a portal) and freeloaders (which MS would >> dearly love to leave in the dust, but can not for PR reasons). > > I make no claim as to why MS does anything... you brought up MS not > me. But I thank you for the lesson in conspiracy theory. It's not a conspiracy theory it's a well documented fact. MS started by pulling updates from windows copies. When people complained this would create a pool of future zombies and threatened to sue MS, MS restored auto-updates for everyone but restricted them to security stuff. ... > I feel that users who rely on auto-updating for security would get a > false sense of security by auto-updating without there being a > notifcation mechanism to clearly notify the user of unapplied security > updates asap. I believe that a false sense of security can be more > dangerous than actual insecurity because a false sense of security > will embolden some people to take risks they otherwise would not if > they knew their were vulnerable. Feel free to disagree. Again, your concern is touching but you've thoroughly lost touch with what a real user is. A real user does not read error messages. Apps must to the best job they can without bothering the user. The typical blunder is an app writer which adds a warning popup to its app to make people check some stuff instead of automating the checking (because he's not sure the automated check will work in 100% of cases). Now most users will just click through so the check is not done at all, and apps crash. The real false sense of security is not users not acting because they're not warned enough, but app writers considering that they just have to dump a particularly evil warning on users to make them do the difficult stuff. USERS DO NOT CARE. If you want stuff to be done, automate it and never rely on users. Even if you only do 60% of the problem space that's 60% more of what you'll achieve with a user warning (most of the times, power users excepted). Now, in this particular case, if you really trust warnings you can do a partial update then print the packages still to be updated (in bold blinking red with copy to the root mail account if you want to). But the truth is users get used to warnings real quick, so if you actually want this to be effective you'd better not do it every single time you hit a partially updated mirror. Users that get yelled at all week round by apps either 1. do not care anymore (mostly young people) or, 2. are terrified of clicking on any new button since it will trigger new abuse (older people) If making people do stuff was that easy carpet-bombing add campaigns would not exist. -- Nicolas Mailhot From wrrhdev at riede.org Tue Dec 6 00:05:48 2005 From: wrrhdev at riede.org (Willem Riede) Date: Tue, 06 Dec 2005 00:05:48 +0000 Subject: yum plugin suggestion or yum change? In-Reply-To: <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> (from jspaleta@gmail.com on Mon Dec 5 11:17:46 2005) References: <20051205125601.GA14554@jadzia.bu.edu> <6280325c0512050459p75e4c412s3b73bce2561fa9c4@mail.gmail.com> <20051205130052.GC19731@ryoko.camperquake.de> <439442E4.8010001@redhat.com> <20051205135330.GA16208@jadzia.bu.edu> <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> Message-ID: <1133827548l.12836l.1l@serve.riede.org> On 12/05/2005 11:17:46 AM, Jeff Spaleta wrote: > > I don't think this project can provide that facility > "reliably" for the majority of users. You postulate this without providing evidence. Please do so. Regards, Willem Riede. From wrrhdev at riede.org Tue Dec 6 00:09:55 2005 From: wrrhdev at riede.org (Willem Riede) Date: Tue, 06 Dec 2005 00:09:55 +0000 Subject: yum plugin suggestion or yum change? In-Reply-To: <604aa7910512051111u4c9dfcdes151961ffc3796f51@mail.gmail.com> (from jspaleta@gmail.com on Mon Dec 5 14:11:19 2005) References: <439442E4.8010001@redhat.com> <20051205135330.GA16208@jadzia.bu.edu> <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> <43947D1C.6030704@insitesinc.com> <43947DD5.1060207@redhat.com> <604aa7910512051111u4c9dfcdes151961ffc3796f51@mail.gmail.com> Message-ID: <1133827795l.12836l.2l@serve.riede.org> On 12/05/2005 02:11:19 PM, Jeff Spaleta wrote: > > "I'm getting 90% of the updates I should be quite safe...I'm sure if > it was an important security issue they'd fix it asap no need for me > to report it...." The people for whom (partial) automatic update is a life saver are the ones that you wouldn't be able to get to report anything come hell or high water. Regards, Willem Riede. From jkeating at j2solutions.net Tue Dec 6 14:00:47 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 06 Dec 2005 09:00:47 -0500 Subject: yum plugin suggestion or yum change? In-Reply-To: <4394BF1A.9010208@bluga.net> References: <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> <43947D1C.6030704@insitesinc.com> <604aa7910512051021q35bd94ai59316ea025c0ab7a@mail.gmail.com> <439494CC.3010502@laposte.net> <604aa7910512051243g66f1394cg5e805f91daea620b@mail.gmail.com> <4394BBE9.6010009@laposte.net> <604aa7910512051420s4a6e1c11o1065d400adcd4612@mail.gmail.com> <4394BF1A.9010208@bluga.net> Message-ID: <1133877647.4139.15.camel@localhost.localdomain> On Mon, 2005-12-05 at 15:28 -0700, Joshua Eichorn wrote: > > They have high-priority updates and optional updates. > > High priority updates get installed by automatic updates, optional have > to updated by hand from windows update. > > most security fixes are High-Priority > > No major upgrades are, ie the new version of windows media player or the > .net framework won't be updated automatically. > > Of course there are also service packs in the mix, which are forced > upgrades at some point since new security fixes are only available if > you install them. Something that they've done recently which will not help the zombie market is prevented systems from updating any further beyond SP2 that haven't done a 'System Validation'. Part of that validation is product activation. non activated products can no longer get updates at all (after SP2). And whoever is thinking that the windows update model is a good target, try doing a stock XP install. Not integrated w/ SP2, just an XP install. There is I believe 2 rounds of update/reboot even before the SP2 install, which is another round of update/reboot. There may be one more round after that before the validation cut off. I think it was a total of 4 rounds of update/reboots that I had to do before I could go no further. -- jes From rodd at clarkson.id.au Tue Dec 6 02:48:02 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Tue, 06 Dec 2005 13:48:02 +1100 Subject: Yum bug? In-Reply-To: <604aa7910512051400g741b73fejfb18ab73a811a350@mail.gmail.com> References: <4394B78C.6050009@conversis.de> <604aa7910512051400g741b73fejfb18ab73a811a350@mail.gmail.com> Message-ID: <1133837283.3762.15.camel@localhost.localdomain> On Mon, 2005-12-05 at 17:00 -0500, Jeff Spaleta wrote: > On 12/5/05, Dennis Jacobfeuerborn wrote: > > Not sure if I should file a bug or if I'm doing something wrong on my end? > > bug already reported to the lists repeatedly, and reported in bugzilla > and the fix should be in rawhide "soon" since the fc4 test update > that fixes this already exists. > > work-around for now remove all the files named "cachecookie" in your > /var/cache/yum tree > or wait 8 hours for the cookies to expire. jef, I know you're trying to help (and your help is appreciated), but at this point, it's probably better to just respond to these messages with 'solution already discussed' and 'search the archives'. This forces the individual asking the question to learn how to search the archives, rather than just asking. Personally, I'm sick of the number of times this question has been asked. Seriously fed up. I'm a patient person, and I don't mind a little repetition, but in this case the solution exists in a number of emails both on test-list and devel-list and the problem is related to the basic update mechanism for fedora - yum, so in my opinion, this is something that everyone on the list should just read. Yum is (like it or not) core funcationality for fedora, so if you're not paying attention to what's happening to yum, or kernels, or the likes then you don't get to ask the same question for the 20th time. Sorry if this is a little harsh, but we're about to get back into test releases which means having people ask the same questions over and over and over (etc) because it's easier than actually reading the list they are subscribed to, or searching the archives. R. -- "It's a fine line between denial and faith. It's much better on my side" From nicolas.mailhot at laposte.net Tue Dec 6 07:45:27 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 06 Dec 2005 08:45:27 +0100 Subject: yum plugin suggestion or yum change? In-Reply-To: <1133877647.4139.15.camel@localhost.localdomain> References: <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> <43947D1C.6030704@insitesinc.com> <604aa7910512051021q35bd94ai59316ea025c0ab7a@mail.gmail.com> <439494CC.3010502@laposte.net> <604aa7910512051243g66f1394cg5e805f91daea620b@mail.gmail.com> <4394BBE9.6010009@laposte.net> <604aa7910512051420s4a6e1c11o1065d400adcd4612@mail.gmail.com> <4394BF1A.9010208@bluga.net> <1133877647.4139.15.camel@localhost.localdomain> Message-ID: <43954197.5030604@laposte.net> Jesse Keating wrote: > Something that they've done recently which will not help the zombie > market is prevented systems from updating any further beyond SP2 that > haven't done a 'System Validation'. Part of that validation is product > activation. non activated products can no longer get updates at all > (after SP2). They can, a pirated copy can't pass the tests on the update portal but will still get the autoupdate security feed > And whoever is thinking that the windows update model is a good target, > try doing a stock XP install. I'm not writing it's the best one, I'm writting it's better than the current yum model. MS started at the point we are now (in case of problems, bail out), then after getting bashed for years for bad security made 100% transparent security auto updates mandatory. And guess what ? It works (modulo the quality of the updates themselves, I'll be the first to admit rpm updates tend to crash less than windows patches, but this is pretty orthogonal and not something yum can claim for itself) -- Nicolas Mailhot From lamont at gurulabs.com Tue Dec 6 08:47:37 2005 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Tue, 6 Dec 2005 01:47:37 -0700 Subject: HTTP Load balancer In-Reply-To: References: Message-ID: <200512060147.42441.lamont@gurulabs.com> On Monday 05 December 2005 11:51am, Mike McGrath wrote: > I understand that Apache 2.2 might make it into FC5 (Its currently in > test 1). I was wondering if there were any plans beyond that to include > an HTTP based load balancer? Perhaps a TCP based balancer? Squid is already in the box. If you want true load-balancing, Squid is great. Plus, it scales very nicely. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] -------------- 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 Tue Dec 6 11:26:28 2005 From: buildsys at redhat.com (Build System) Date: Tue, 6 Dec 2005 06:26:28 -0500 Subject: rawhide report: 20051206 changes Message-ID: <200512061126.jB6BQSrv021017@porkchop.devel.redhat.com> Updated Packages: amtu-1.0.2-2 ------------ * Mon Dec 05 2005 Steve Grubb 1.0.2-2 - Fix %clean section of spec file (bz 172942) - Add memsep-random patch (bz 174767) anaconda-10.90.13-1 ------------------- * Mon Dec 05 2005 Chris Lumens 10.90.13-1 - Reword media check dialog (dcentrell, #174530). - gcc41 compile fixes (pjones). - Add genhomedircon, setfiles, and /etc/shells for selinux. * Thu Dec 01 2005 Jeremy Katz - 10.90.12-1 - some release notes viewer fixing (dcantrell) - allow %pre scripts in an %include (clumens, #166100) - fix the squashfs stuff to actually work - hack around slang not initializing utf8 mode so that we have line drawing chars (#174761) * Thu Dec 01 2005 Jeremy Katz - 10.90.11-1 - reworded media check prompt (dcantrell, #174472) - let's try squashfs... audit-1.1.2-1 ------------- * Mon Dec 05 2005 Steve Grubb 1.1.2-1 - Add more message types authconfig-5.0.4-1 ------------------ * Mon Dec 05 2005 Tomas Mraz - 5.0.4-1 - don't ignore krb5realm command line option (#174838) - read dns_lookup_realm and dns_lookup_kdc values correctly - the PAM configuration is now written in system-auth-ac file which is then symlinked from system-auth, the symlink is not overwritten so local PAM configuration is now possible (#165342) avahi-0.6-6 ----------- * Mon Dec 05 2005 Jason Vas Dias - 0.6-6 - fix bug 174799 - fix .spec file \%files permissions cdrtools-8:2.01.01.0.a03-1 -------------------------- * Mon Dec 05 2005 Harald Hoyer 8:2.01.01.0.a03-1 - version 2.01.01a03 - DVD patch from http://crashrecovery.org/oss-dvd.html adds support for DVD+RW and DVD+R DL burning cryptsetup-luks-1.0.1-4 ----------------------- * Mon Dec 05 2005 Bill Nottingham 1.0.1-4 - rebuild against new libdevmapper * Thu Oct 13 2005 Florian La Roche - add -lsepol to rebuild on current fc5 dhcp-11:3.0.3-16 ---------------- * Mon Dec 05 2005 Jason Vas Dias - 11:3.0.3-16 - fix gcc 4.1 compile warnings (-Werror) evolution-data-server-1.4.2.1-1 ------------------------------- * Mon Dec 05 2005 David Malcolm - 1.4.2.1-1 - 1.4.2.1 gtkspell-2.0.11-1 ----------------- * Mon Dec 05 2005 David Malcolm - 2.0.11-1 - 2.0.11 httpd-2.2.0-2 ------------- * Mon Dec 05 2005 Joe Orton 2.2.0-2 - don't strip C-L from HEAD responses (Greg Ames, #110552) - load mod_proxy_balancer by default - add proxy_ajp.conf to load/configure mod_proxy_ajp - Obsolete mod_jk - update docs URLs in httpd.conf/ssl.conf ipsec-tools-0.6.3-1 ------------------- * Mon Dec 05 2005 Harald Hoyer 0.6.3-1 - version 0.6.3, which contains fixes for various DoS problems iputils-20020927-31 ------------------- * Fri Dec 02 2005 Radek Vokal 20020927-31 - ifenslave.8 from debian.org - separate ifenslave to its own tarball kdegames-6:3.5.0-1 ------------------ * Mon Dec 05 2005 Than Ngo 6:3.5.0-1 - 3.5 kernel-2.6.14-1.1740_FC5 ------------------------ * Mon Dec 05 2005 Dave Jones - 2.6.15-rc5-git1 libgsf-1.13.3-2 --------------- * Mon Dec 05 2005 Caolan McNamara 1.13.3-2 - rh#172062# Obsolete extras libgsf113 libsepol-1.9.42-1 ----------------- * Mon Dec 05 2005 Dan Walsh 1.9.42-1 - Upgrade to latest from NSA * Dropped handle from user_del_role interface. logwatch-7.1-3 -------------- * Tue Nov 29 2005 Ivana Varekova 7.1-3 - add secure service patch - add iptables patch created by Allen Kistler (bug 174954) - add audit service patch mdadm-2.2-1.fc5 --------------- * Mon Dec 05 2005 Warren Togami 2.2-1 - 2.2 upgrade (#167897) - disable diet because we don't ship it anymore and we don't actually use mdassemble now mod_auth_kerb-5.0-8 ------------------- * Mon Dec 05 2005 Joe Orton 5.0-8 - rebuild for httpd 2.2 mod_auth_mysql-1:3.0.0-2 ------------------------ * Mon Dec 05 2005 Joe Orton 1:3.0.0-2 - update to 3.0.0 mod_auth_pgsql-2.0.1-9 ---------------------- * Mon Dec 05 2005 Joe Orton 2.0.1-9 - rebuild for httpd-2.2 - don't strip DSO so debuginfo works mod_authz_ldap-0.26-6 --------------------- * Mon Dec 05 2005 Joe Orton 0.26-6 - link against -lldap and -lcrypto * Mon Dec 05 2005 Joe Orton 0.26-5 - rebuild for httpd 2.2 - fix ssl_var_lookup() use in certmap.c policycoreutils-1.27.36-1 ------------------------- * Mon Dec 05 2005 Dan Walsh 1.27.36-1 - Update to match NSA * Changed genhomedircon to warn on use of ROLE in homedir_template if using managed policy, as libsemanage does not yet support it. rhythmbox-0.9.2-3 ----------------- * Mon Dec 05 2005 Matthias Clasen - rebuild selinux-policy-2.0.9-1 ---------------------- * Fri Dec 02 2005 Dan Walsh 2.0.9-1. Update from upstream xscreensaver-1:4.22-21 ---------------------- * Mon Dec 05 2005 Ray Strode 1:4.22-21 - Update list_files function to fix ownership issues. Patch from Mamoru Tasaka (mtasaka at ioa.s.u-tokyo.ac.jp) (bug 161728). * Tue Nov 01 2005 Ray Strode 1:4.22-20 - Switch requires to modular X yum-2.4.1-2 ----------- * Mon Dec 05 2005 Jeremy Katz - 2.4.1-2 - add Panu's patch for cachecookie cleaning (#174715) - change default cache time to 30 minutes to match new upstream Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel = 0:2.6.14-1.1696_FC5 cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5smp cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel = 0:2.6.14-1.1696_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 mod_jk - 1.2.6-3jpp_4fc.i386 requires httpd-mmn = 0:20020903 Broken deps for ia64 ---------------------------------------------------------- k3b - 0.12.4-0.a.1.ia64 requires libdbus-qt-1.so.1()(64bit) k3b - 0.12.4-0.a.1.ia64 requires libdbus-1.so.1()(64bit) mod_jk - 1.2.6-3jpp_4fc.ia64 requires httpd-mmn = 0:20020903 rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 mod_jk - 1.2.6-3jpp_4fc.ppc requires httpd-mmn = 0:20020903 Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 k3b - 0.12.4-0.a.1.ppc64 requires libdbus-qt-1.so.1()(64bit) k3b - 0.12.4-0.a.1.ppc64 requires libdbus-1.so.1()(64bit) mod_jk - 1.2.6-3jpp_4fc.ppc64 requires httpd-mmn = 0:20020903 Broken deps for s390 ---------------------------------------------------------- mod_jk - 1.2.6-3jpp_4fc.s390 requires httpd-mmn = 0:20020903 rhythmbox - 0.9.1-1.s390 requires libdbus-1.so.1 rhythmbox - 0.9.1-1.s390 requires libdbus-glib-1.so.1 Broken deps for s390x ---------------------------------------------------------- mod_jk - 1.2.6-3jpp_4fc.s390x requires httpd-mmn = 0:20020903 rhythmbox - 0.9.1-1.s390x requires libdbus-1.so.1()(64bit) rhythmbox - 0.9.1-1.s390x requires libdbus-glib-1.so.1()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 mod_jk - 1.2.6-3jpp_4fc.x86_64 requires httpd-mmn = 0:20020903 From reuben-fedora-devel at reub.net Tue Dec 6 12:21:28 2005 From: reuben-fedora-devel at reub.net (Reuben Farrelly) Date: Wed, 07 Dec 2005 01:21:28 +1300 Subject: Dovecot 1.0 In-Reply-To: <43938738.3090906@develer.com> References: <1133705505l.3795l.0l@serve.riede.org> <43938738.3090906@develer.com> Message-ID: <43958248.40509@reub.net> On 5/12/2005 1:18 p.m., Bernardo Innocenti wrote: > Willem Riede wrote: > >> Can we have dovecot 1.0 alpha4 in FC5? Even though the word alpha is >> present in the version, it is quite stable, and fixes many problems that >> there are in 0.99.14. As a matter of fact, there is no upstream support >> for 0.99.x. Any reports are met with 'please upgrade and your problem >> will likely be over'. > > Yes, please! I was waiting for Dovecot 1.0 to switch to Dovecot > from courier-imap without anyone noticing the difference. > > The feature I'm missing in 0.99 is namespaces. Without this, > I'd have to reconfigure all the MUAs to change their IMAP > prefix from "INBOX" to "" (empty string). I would like to add my +1 to this as well. Dovecot-0.99.x is arguably just as bad if not more 'alpha' than the upcoming 1.0 releases both in terms of bugs and of features and it seems most odd to be shipping a package that isn't supported by the upstream developer and community. I would also put the case that 0.99.x was more 'alpha' in it's quality than the current releases that are actually labelled as 'alpha'. Anyway, there is a bugzilla entry open as an RFE for it: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170960 Perhaps that might be a good place to start adding comments, maybe if enough people ask nicely in there and show support, it might happen from within RH ;-) From memory last time I needed to there was very little work required to repackage the 1.0 tarballs using the existing 0.99.x spec file. The RFE above additionally talks about dovecot-lda being made available as a separate package, but I think at this stage it is secondary to actually getting the primary package updated in the distribution. Perhaps the lda component could start off in extras :) I'm sure that if all that is missing for it to happen is someone to do some specfile hacking, someone in the community will step up to the mark (and I'll go digging throught the stuff I did to see how I last did it if I need to). reuben From stickster at gmail.com Tue Dec 6 13:05:50 2005 From: stickster at gmail.com (Paul W. Frields) Date: Tue, 06 Dec 2005 08:05:50 -0500 Subject: Stupid (?) lib64 questions Message-ID: <1133874350.4093.10.camel@localhost.localdomain> I have an x86 system, running only official FC4 + Extras, on which I am seeing a few packages that are referencing "/usr/lib64": (1) - php*-5.0.4-10.5, which now is trying to find the mysql module under /usr/lib64 instead of /usr/lib. (2) - My Fedora Extras blogtk-1.1-4.fc4 package, built on hammer1.f.r.c, contains files that are installed under /usr/lib64. Although the latter doesn't appear to affect proper functioning, the former is wreaking havoc now that I am testing a package that uses php-mysql, since it is looking for /usr/lib64/php4/modules/mysql.so and not finding it there. (I can fix this with a symbolic link.) My understanding is that the former situation is probably a bug, which I'll file, but what is up with the latter? Is it to be expected that FE stuff will sometimes end up with %{_libdir} evaluating to /usr/lib64 on build machines? Clues delivered gently would be helpful. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- 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 Tue Dec 6 13:22:42 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 06 Dec 2005 13:22:42 +0000 Subject: Stupid (?) lib64 questions In-Reply-To: <1133874350.4093.10.camel@localhost.localdomain> References: <1133874350.4093.10.camel@localhost.localdomain> Message-ID: <1133875362.4136.123.camel@baythorne.infradead.org> On Tue, 2005-12-06 at 08:05 -0500, Paul W. Frields wrote: > Is it to be expected that FE stuff will sometimes end up with > %{_libdir} evaluating to /usr/lib64 on build machines? Clues > delivered gently would be helpful. There is an RPM bug which causes this kind of behaviour -- if /etc/rpm/platform specifies a 64-bit platform, then %{_libdir} is set to /usr/lib64 even when building for a 32-bit target. A workaround is to edit /etc/rpm/platform before building 32-bit packages on a 64-bit machine. And then remember to put it back again before running 'yum update' on that machine :) -- dwmw2 From czar at czarc.net Tue Dec 6 14:09:47 2005 From: czar at czarc.net (Gene C.) Date: Tue, 6 Dec 2005 09:09:47 -0500 Subject: yum plugin suggestion or yum change? In-Reply-To: <604aa7910512051243g66f1394cg5e805f91daea620b@mail.gmail.com> References: <439494CC.3010502@laposte.net> <604aa7910512051243g66f1394cg5e805f91daea620b@mail.gmail.com> Message-ID: <200512060909.47654.czar@czarc.net> On Monday 05 December 2005 15:43, Jeff Spaleta wrote: > On 12/5/05, Nicolas Mailhot wrote: > > Do you know why windows security sucks ? It's not because the patches > > does not exist, it's just that applying them has historically been so > > painful people do not bother. Why are you purposefully making yum use > > painful as well ? > > I'm really not sure why you decided to through this in...but I'll > bite. Yes or no... does Microsoft's XP auto updater understands the > difference between critical and non-critical updates and does it offer > all available updates as part of automated facility? > > Does MS's updater allow some critical updates to fail? Apparently yes! Anecdotal evidence: http://www.transterrestrial.com/archives/006085.html#006085 -- Gene From d.jacobfeuerborn at conversis.de Tue Dec 6 15:26:23 2005 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Tue, 06 Dec 2005 16:26:23 +0100 Subject: Yum bug? In-Reply-To: <1133837283.3762.15.camel@localhost.localdomain> References: <4394B78C.6050009@conversis.de> <604aa7910512051400g741b73fejfb18ab73a811a350@mail.gmail.com> <1133837283.3762.15.camel@localhost.localdomain> Message-ID: <4395AD9F.7070700@conversis.de> Rodd Clarkson wrote: > On Mon, 2005-12-05 at 17:00 -0500, Jeff Spaleta wrote: >> On 12/5/05, Dennis Jacobfeuerborn wrote: >>> Not sure if I should file a bug or if I'm doing something wrong on my end? >> bug already reported to the lists repeatedly, and reported in bugzilla >> and the fix should be in rawhide "soon" since the fc4 test update >> that fixes this already exists. >> >> work-around for now remove all the files named "cachecookie" in your >> /var/cache/yum tree >> or wait 8 hours for the cookies to expire. > > jef, > > I know you're trying to help (and your help is appreciated), but at this > point, it's probably better to just respond to these messages with > 'solution already discussed' and 'search the archives'. > > This forces the individual asking the question to learn how to search > the archives, rather than just asking. > > Personally, I'm sick of the number of times this question has been > asked. Seriously fed up. I'm a patient person, and I don't mind a > little repetition, but in this case the solution exists in a number of > emails both on test-list and devel-list and the problem is related to > the basic update mechanism for fedora - yum, so in my opinion, this is > something that everyone on the list should just read. Yum is (like it > or not) core funcationality for fedora, so if you're not paying > attention to what's happening to yum, or kernels, or the likes then you > don't get to ask the same question for the 20th time. > > Sorry if this is a little harsh, but we're about to get back into test > releases which means having people ask the same questions over and over > and over (etc) because it's easier than actually reading the list they > are subscribed to, or searching the archives. > > > R. > Look, I searched on both bugzilla and in the devel archives. I failed to see the bug in bugzilla, my bad, I'm an idiot. However I do read the devel list daily and cannot remember reading anything about this problem. Searching for "repomd.xml" lists exactly two mails as of now, my own and one reply. Searching for "cachecookie" (once you actually now this has something to do with "cachecookie") lists three mails, two replies to this thread and the latest rawhide report showing that this was fixed. I tried to find, failed, and will now accept my shame and commit seppuku. Having said that I think on a public mailing-list you will simply have to live with the imperfection of human beeings. I promise I'll search more thoroughly the next time but even then I cannot provide you with a guarantee that I will always be successfull. While I see that this kind of stuff can be annoying I cannot understand why someone can get so wound up about it. It was just a mail. Sorry, Dennis From ph18 at cornell.edu Tue Dec 6 15:30:07 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Tue, 06 Dec 2005 10:30:07 -0500 Subject: yum plugin suggestion or yum change? In-Reply-To: <4394C2A3.1090602@laposte.net> References: <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> <43947D1C.6030704@insitesinc.com> <604aa7910512051021q35bd94ai59316ea025c0ab7a@mail.gmail.com> <439494CC.3010502@laposte.net> <604aa7910512051243g66f1394cg5e805f91daea620b@mail.gmail.com> <4394BBE9.6010009@laposte.net> <604aa7910512051420s4a6e1c11o1065d400adcd4612@mail.gmail.com> <4394C2A3.1090602@laposte.net> Message-ID: <4395AE7F.7000001@cornell.edu> Nicolas Mailhot wrote: > > MS reasons for holding back some stuff are not applicable to Fedora. > Fedora userbase is not segmented between legitimate users (which can get > full updates by going through a portal) and freeloaders (which MS would > dearly love to leave in the dust, but can not for PR reasons). > > Not just PR. Windows computers running a stolen operating system are a threat to Windows computers running a legitimate operating system -- and, when traffic levels get high, to all other computers. Also, there are a lot of Windows installations that are paid up but the licenses aren't quite in order: a lot of sites use tools like Ghost to maintain desktops, and it's hard to get licensing right in that situation. Similar pressures would apply to RHEL 4 if RHEL 4 were an attractive target. Overall, my experience is that packages become unupdatable over time in a rawhide or FC# system -- most of the time these are packages I don't care about, so I throw them overboard. If something I cared about became unupdatable, I'd have a real problem. From skvidal at phy.duke.edu Tue Dec 6 15:35:03 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 06 Dec 2005 10:35:03 -0500 Subject: yum plugin suggestion or yum change? In-Reply-To: <4395AE7F.7000001@cornell.edu> References: <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> <43947D1C.6030704@insitesinc.com> <604aa7910512051021q35bd94ai59316ea025c0ab7a@mail.gmail.com> <439494CC.3010502@laposte.net> <604aa7910512051243g66f1394cg5e805f91daea620b@mail.gmail.com> <4394BBE9.6010009@laposte.net> <604aa7910512051420s4a6e1c11o1065d400adcd4612@mail.gmail.com> <4394C2A3.1090602@laposte.net> <4395AE7F.7000001@cornell.edu> Message-ID: <1133883303.11387.11.camel@cutter> > Not just PR. Windows computers running a stolen operating system > are a threat to Windows computers running a legitimate operating system > -- and, when traffic levels get high, to all other computers. Also, > there are a lot of Windows installations that are paid up but the > licenses aren't quite in order: a lot of sites use tools like Ghost to > maintain desktops, and it's hard to get licensing right in that situation. > > Similar pressures would apply to RHEL 4 if RHEL 4 were an attractive > target. > > Overall, my experience is that packages become unupdatable over > time in a rawhide or FC# system -- most of the time these are packages I > don't care about, so I throw them overboard. If something I cared > about became unupdatable, I'd have a real problem. OKAY Let's STOP debating this. If there is working code to present as a plugin then PLEASE do so. otherwise all this talk is just masturbation. -sv From czar at czarc.net Tue Dec 6 15:58:38 2005 From: czar at czarc.net (Gene C.) Date: Tue, 6 Dec 2005 10:58:38 -0500 Subject: yum annoyances Message-ID: <200512061058.38491.czar@czarc.net> I call the following annoyances rather than bugs because yum is working as designed. What I really wondering is if an enhancement to yum is appropriate. While it may be appropriate, these cases may also be in the "too hard" or "not worth the effort" category. I will also caveat this by saying that I have only seen these cases working with the development tree and not with "production" version. I will also say that a "fresh install" will not have the problem but, even in development, I prefer updating rather than installing unless I am testing the installer. Case 1: A package is install but, now, has been deleted from the development/update tree and the installed package blocks updates. The current answer is to manually remove the package (yum remove or rpm -e) if, and only if, you know that package was deleted .. the recent case of dbus-qt. Would it be possible to have some metadata which would flag to yum that the package needs to be removed. Case 2: This is similar to case 1. In this case, an older version of a package is in the development/update tree, The currently installed packages include one or more packages which are a "more recent version" but one that has problems ... therefore, we need to "roll back" the package. Again, this can be handled manually via yum remove/install or using rpm --oldpackage if you know that the situation exists. -- Gene From skvidal at phy.duke.edu Tue Dec 6 16:11:10 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 06 Dec 2005 11:11:10 -0500 Subject: yum annoyances In-Reply-To: <200512061058.38491.czar@czarc.net> References: <200512061058.38491.czar@czarc.net> Message-ID: <1133885470.11387.17.camel@cutter> > Case 1: A package is install but, now, has been deleted from the > development/update tree and the installed package blocks updates. The > current answer is to manually remove the package (yum remove or rpm -e) if, > and only if, you know that package was deleted .. the recent case of dbus-qt. > Would it be possible to have some metadata which would flag to yum that the > package needs to be removed. We have that, it is called an obsolete. However, if nothing else obsoletes the package there is nothing we could or should do. To have an arbitrary 'remove this' element in the metadata would just be explosively dangerous. I can see the typo of glibc from glib. It would be like a million machines cried out and then were instantly silenced. > Case 2: This is similar to case 1. In this case, an older version of a > package is in the development/update tree, The currently installed packages > include one or more packages which are a "more recent version" but one that > has problems ... therefore, we need to "roll back" the package. Again, this > can be handled manually via yum remove/install or using rpm --oldpackage if > you know that the situation exists. I've never seen that happen in the update tree. In the development tree, sure - that's what happens in rawhide. Shit breaks. -sv From fedora at camperquake.de Tue Dec 6 16:09:59 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 6 Dec 2005 17:09:59 +0100 Subject: yum annoyances In-Reply-To: <200512061058.38491.czar@czarc.net> References: <200512061058.38491.czar@czarc.net> Message-ID: <20051206160959.GA6117@ryoko.camperquake.de> On Tue, Dec 06, 2005 at 10:58:38AM -0500, Gene C. wrote: > Would it be possible to have some metadata which would flag to yum that the > package needs to be removed. yum does not know if you want the package removed or not. But it could indicate that none of the repos used for this resolver run provides this package or a package which obsoletes it. > Case 2: This is similar to case 1. In this case, an older version of a > package is in the development/update tree, The currently installed packages > include one or more packages which are a "more recent version" but one that > has problems ... therefore, we need to "roll back" the package. Again, this > can be handled manually via yum remove/install or using rpm --oldpackage if > you know that the situation exists. Multiple versions of one package in a repo is not the usual case. From skvidal at phy.duke.edu Tue Dec 6 16:12:48 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 06 Dec 2005 11:12:48 -0500 Subject: yum annoyances In-Reply-To: <20051206160959.GA6117@ryoko.camperquake.de> References: <200512061058.38491.czar@czarc.net> <20051206160959.GA6117@ryoko.camperquake.de> Message-ID: <1133885568.11387.19.camel@cutter> On Tue, 2005-12-06 at 17:09 +0100, Ralf Ertzinger wrote: > On Tue, Dec 06, 2005 at 10:58:38AM -0500, Gene C. wrote: > > > Would it be possible to have some metadata which would flag to yum that the > > package needs to be removed. > > yum does not know if you want the package removed or not. But it could > indicate that none of the repos used for this resolver run provides > this package or a package which obsoletes it. yum list extras. -sv From fedora at camperquake.de Tue Dec 6 16:17:36 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 6 Dec 2005 17:17:36 +0100 Subject: yum annoyances In-Reply-To: <1133885568.11387.19.camel@cutter> References: <200512061058.38491.czar@czarc.net> <20051206160959.GA6117@ryoko.camperquake.de> <1133885568.11387.19.camel@cutter> Message-ID: <20051206161736.GB6117@ryoko.camperquake.de> On Tue, Dec 06, 2005 at 11:12:48AM -0500, seth vidal wrote: > > yum does not know if you want the package removed or not. But it could > > indicate that none of the repos used for this resolver run provides > > this package or a package which obsoletes it. > > > yum list extras. Not quite. Let me reword the above: But it could indicate that none of the repos used for this resolver run provides this package, a package which upgrades it or a package which obsoletes it. From bgerst at didntduck.org Tue Dec 6 16:26:42 2005 From: bgerst at didntduck.org (Brian Gerst) Date: Tue, 06 Dec 2005 11:26:42 -0500 Subject: yum annoyances In-Reply-To: <1133885568.11387.19.camel@cutter> References: <200512061058.38491.czar@czarc.net> <20051206160959.GA6117@ryoko.camperquake.de> <1133885568.11387.19.camel@cutter> Message-ID: <4395BBC2.9060602@didntduck.org> seth vidal wrote: > On Tue, 2005-12-06 at 17:09 +0100, Ralf Ertzinger wrote: > >>On Tue, Dec 06, 2005 at 10:58:38AM -0500, Gene C. wrote: >> >> >>>Would it be possible to have some metadata which would flag to yum that the >>>package needs to be removed. >> >>yum does not know if you want the package removed or not. But it could >>indicate that none of the repos used for this resolver run provides >>this package or a package which obsoletes it. > > > > yum list extras. The problem with list extras is that it doesn't differentiate when a package is extra because a newer version exists or if the package doesn't exist in the repo. -- Brian Gerst From mattdm at mattdm.org Tue Dec 6 16:48:47 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 6 Dec 2005 11:48:47 -0500 Subject: yum annoyances In-Reply-To: <200512061058.38491.czar@czarc.net> References: <200512061058.38491.czar@czarc.net> Message-ID: <20051206164847.GA7926@jadzia.bu.edu> On Tue, Dec 06, 2005 at 10:58:38AM -0500, Gene C. wrote: > Case 1: A package is install but, now, has been deleted from the > development/update tree and the installed package blocks updates. The > current answer is to manually remove the package (yum remove or rpm -e) > if, and only if, you know that package was deleted .. the recent case of > dbus-qt. This could be worked around with an "obsolete-packages" rpm in the repository, which would mark as Obsolete all such known packages. [...] > Case 2: This is similar to case 1. In this case, an older version of a > package is in the development/update tree, The currently installed > packages include one or more packages which are a "more recent version" > but one that has problems ... therefore, we need to "roll back" the > package. Again, this can be handled manually via yum remove/install or > using rpm --oldpackage if you know that the situation exists. In the non-devel tree, this is "solved" with Epochs. In the devel tree, I'd say the best thing to do is watch closely, because you're using the development tree. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From brugolsky at telemetry-investments.com Tue Dec 6 16:50:41 2005 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Tue, 6 Dec 2005 11:50:41 -0500 Subject: Stupid (?) lib64 questions In-Reply-To: <1133875362.4136.123.camel@baythorne.infradead.org> References: <1133874350.4093.10.camel@localhost.localdomain> <1133875362.4136.123.camel@baythorne.infradead.org> Message-ID: <20051206165041.GD6438@ti64.telemetry-investments.com> On Tue, Dec 06, 2005 at 01:22:42PM +0000, David Woodhouse wrote: > A workaround is to edit /etc/rpm/platform before building 32-bit > packages on a 64-bit machine. And then remember to put it back again > before running 'yum update' on that machine :) Setting up an alternate build environment is the type of thing that I like to do with bind mounts in a private namespace. There's no standard tool yet to create a private namespace, I simply use one that I hacked up; with the merging of shared subtrees into 2.6.15, that ought to change. The v9fs folks may have a set of userland tools available. First, sed -e 's/x86_64/i686/;s/ppc64/ppc32/;s/s390x/s390/' \ /etc/rpm/platform > /etc/rpm/platform32 In a private namespace, you can do something like: mount -n --bind /etc/rpm/plaform32 /etc/rpm/platform ... Regards, Bill Rugolsky From dwmw2 at infradead.org Tue Dec 6 16:54:53 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 06 Dec 2005 16:54:53 +0000 Subject: Stupid (?) lib64 questions In-Reply-To: <20051206165041.GD6438@ti64.telemetry-investments.com> References: <1133874350.4093.10.camel@localhost.localdomain> <1133875362.4136.123.camel@baythorne.infradead.org> <20051206165041.GD6438@ti64.telemetry-investments.com> Message-ID: <1133888093.4136.158.camel@baythorne.infradead.org> On Tue, 2005-12-06 at 11:50 -0500, Bill Rugolsky Jr. wrote: > sed -e 's/x86_64/i686/;s/ppc64/ppc32/;s/s390x/s390/' \ > /etc/rpm/platform > /etc/rpm/platform32 Shouldn't that be s/ppc64/ppc/ ? -- dwmw2 From dnjinc at wowway.com Tue Dec 6 16:55:42 2005 From: dnjinc at wowway.com (Demond James) Date: Tue, 06 Dec 2005 11:55:42 -0500 Subject: yum plugin suggestion or yum change? In-Reply-To: <1133883303.11387.11.camel@cutter> References: <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> <43947D1C.6030704@insitesinc.com> <604aa7910512051021q35bd94ai59316ea025c0ab7a@mail.gmail.com> <439494CC.3010502@laposte.net> <604aa7910512051243g66f1394cg5e805f91daea620b@mail.gmail.com> <4394BBE9.6010009@laposte.net> <604aa7910512051420s4a6e1c11o1065d400adcd4612@mail.gmail.com> <4394C2A3.1090602@laposte.net> <4395AE7F.7000001@cornell.edu> <1133883303.11387.11.camel@cutter> Message-ID: <4395C28E.2060103@wowway.com> seth vidal wrote: >> Not just PR. Windows computers running a stolen operating system >> are a threat to Windows computers running a legitimate operating system >> -- and, when traffic levels get high, to all other computers. Also, >> there are a lot of Windows installations that are paid up but the >> licenses aren't quite in order: a lot of sites use tools like Ghost to >> maintain desktops, and it's hard to get licensing right in that situation. >> >> Similar pressures would apply to RHEL 4 if RHEL 4 were an attractive >> target. >> >> Overall, my experience is that packages become unupdatable over >> time in a rawhide or FC# system -- most of the time these are packages I >> don't care about, so I throw them overboard. If something I cared >> about became unupdatable, I'd have a real problem. >> > > > OKAY > Let's STOP debating this. If there is working code to present as a > plugin then PLEASE do so. > > otherwise all this talk is just masturbation. > > -sv > > > THANK YOU!!!! This was getting out of control Stop the bickering and lets get ideas down for a plugin. If you want this feature then participate if not then Just smile and wave. It's a plugin, use if you like it. Demond From jspaleta at gmail.com Tue Dec 6 17:22:22 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 6 Dec 2005 12:22:22 -0500 Subject: yum annoyances In-Reply-To: <20051206164847.GA7926@jadzia.bu.edu> References: <200512061058.38491.czar@czarc.net> <20051206164847.GA7926@jadzia.bu.edu> Message-ID: <604aa7910512060922k33bfcb9bv19e4ae157de470e4@mail.gmail.com> On 12/6/05, Matthew Miller wrote: > This could be worked around with an "obsolete-packages" rpm in the > repository, which would mark as Obsolete all such known packages. Is that really appropriate? To unleash a package in a repository that will remove functionality from a client system? What happens to user who were relying on that functionality? Its one thing to obsolete because of a package name change where the new package provides similar functionality. Its quite another when obsoleting is used in a blank payload package to delibrately remove another package without actually providing similar functionality. -jef From linux_4ever at yahoo.com Tue Dec 6 17:30:15 2005 From: linux_4ever at yahoo.com (Steve G) Date: Tue, 6 Dec 2005 09:30:15 -0800 (PST) Subject: yum annoyances In-Reply-To: <604aa7910512060922k33bfcb9bv19e4ae157de470e4@mail.gmail.com> Message-ID: <20051206173015.54829.qmail@web51506.mail.yahoo.com> On 12/6/05, Matthew Miller wrote: > This could be worked around with an "obsolete-packages" rpm in the > repository, which would mark as Obsolete all such known packages. Seems like an answer might be to have a "check-retired" command. When packages are removed from the repo, they are moved to an area where the retired packages live. Meta-data is built from that directory so there are no typos. Check-retired would not automatically delete packages just like update doesn't automatically update packages. It should print the list for approval and proceed only if the user tells it to. -Steve __________________________________________ Yahoo! DSL ? Something to write home about. Just $16.99/mo. or less. dsl.yahoo.com From skvidal at phy.duke.edu Tue Dec 6 18:18:41 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 06 Dec 2005 13:18:41 -0500 Subject: yum annoyances In-Reply-To: <20051206173015.54829.qmail@web51506.mail.yahoo.com> References: <20051206173015.54829.qmail@web51506.mail.yahoo.com> Message-ID: <1133893121.11387.27.camel@cutter> On Tue, 2005-12-06 at 09:30 -0800, Steve G wrote: > On 12/6/05, Matthew Miller wrote: > > This could be worked around with an "obsolete-packages" rpm in the > > repository, which would mark as Obsolete all such known packages. > > Seems like an answer might be to have a "check-retired" command. When packages > are removed from the repo, they are moved to an area where the retired packages > live. Meta-data is built from that directory so there are no typos. > Check-retired would not automatically delete packages just like update doesn't > automatically update packages. It should print the list for approval and proceed > only if the user tells it to. > sounds like something worth adding to package-cleanup in yum-utils. Care to hack something together? -sv From nicolas.mailhot at laposte.net Tue Dec 6 18:18:47 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 06 Dec 2005 19:18:47 +0100 Subject: yum plugin suggestion or yum change? In-Reply-To: <4395C28E.2060103@wowway.com> References: <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> <43947D1C.6030704@insitesinc.com> <604aa7910512051021q35bd94ai59316ea025c0ab7a@mail.gmail.com> <439494CC.3010502@laposte.net> <604aa7910512051243g66f1394cg5e805f91daea620b@mail.gmail.com> <4394BBE9.6010009@laposte.net> <604aa7910512051420s4a6e1c11o1065d400adcd4612@mail.gmail.com> <4394C2A3.1090602@laposte.net> <4395AE7F.7000001@cornell.edu> <1133883303.11387.11.camel@cutter> <4395C28E.2060103@wowway.com> Message-ID: <4395D607.7080002@laposte.net> Demond James wrote: > THANK YOU!!!! > This was getting out of control > > Stop the bickering and lets get ideas down for a plugin. There wouldn't have been any "bickering" in the first place if instead of insisting partial updates were the wrong thing to do people had admitted at once the real problem was lack of coders. There's no shame in saying you have no time/you're not interested in doing something. OTOH when you trumpet formal opposition to something, do expect people to argue with you. -- Nicolas Mailhot From skvidal at phy.duke.edu Tue Dec 6 18:24:29 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 06 Dec 2005 13:24:29 -0500 Subject: yum plugin suggestion or yum change? In-Reply-To: <4395D607.7080002@laposte.net> References: <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> <43947D1C.6030704@insitesinc.com> <604aa7910512051021q35bd94ai59316ea025c0ab7a@mail.gmail.com> <439494CC.3010502@laposte.net> <604aa7910512051243g66f1394cg5e805f91daea620b@mail.gmail.com> <4394BBE9.6010009@laposte.net> <604aa7910512051420s4a6e1c11o1065d400adcd4612@mail.gmail.com> <4394C2A3.1090602@laposte.net> <4395AE7F.7000001@cornell.edu> <1133883303.11387.11.camel@cutter> <4395C28E.2060103@wowway.com> <4395D607.7080002@laposte.net> Message-ID: <1133893470.11387.29.camel@cutter> On Tue, 2005-12-06 at 19:18 +0100, Nicolas Mailhot wrote: > Demond James wrote: > > > THANK YOU!!!! > > This was getting out of control > > > > Stop the bickering and lets get ideas down for a plugin. > > There wouldn't have been any "bickering" in the first place if instead > of insisting partial updates were the wrong thing to do people had > admitted at once the real problem was lack of coders. There's no shame > in saying you have no time/you're not interested in doing something. > OTOH when you trumpet formal opposition to something, do expect people > to argue with you. > I'm still not convinced that partial updates are an okay thing to do. But someone providing sensible code that handles the ugly corner cases nicely will do a lot toward convincing me. -sv From jspaleta at gmail.com Tue Dec 6 18:22:50 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 6 Dec 2005 13:22:50 -0500 Subject: yum annoyances In-Reply-To: <20051206173015.54829.qmail@web51506.mail.yahoo.com> References: <604aa7910512060922k33bfcb9bv19e4ae157de470e4@mail.gmail.com> <20051206173015.54829.qmail@web51506.mail.yahoo.com> Message-ID: <604aa7910512061022g2444dbedve51d2dc2d3a4d33e@mail.gmail.com> On 12/6/05, Steve G wrote: > Seems like an answer might be to have a "check-retired" command. When packages > are removed from the repo, they are moved to an area where the retired packages > live. Meta-data is built from that directory so there are no typos. They are moved to an area where retired packages live? So the master repository server could never actually fully delete the last version of a particular package? -jef From mihamina.rakotomandimby at etu.univ-orleans.fr Tue Dec 6 18:38:29 2005 From: mihamina.rakotomandimby at etu.univ-orleans.fr (Rakotomandimby Mihamina) Date: Tue, 06 Dec 2005 19:38:29 +0100 Subject: have em2820 em2840 modules in fedora core 4 Message-ID: <1133894309.2832.20.camel@localhost.localdomain> Hi, I have a DAzzle DVC 90 video acquisition device. I see it was added to the kernel supported cards here: http://www.kernel.org/hg/linux-2.6/?fd=6f11eee29e5d;file=Documentation/video4linux/CARDLIST.em28xx Would you know if the Fedora Core 4 flavour kernel embed it? Please tell me what should I do to have it working under Linux. I know how to build rpm from src.rpm if needed (editing the specfile then run rpmbuild with the right options) I ask because with the stock Fedora kernel, the module em2820 and em2840 are not found. Thank you. -- A powerfull GroupWare, CMS, CRM, ECM: CPS (Open Source & GPL). Opengroupware, SPIP, Plone, PhpBB, JetSpeed... are good: CPS is better. http://www.cps-project.org for downloads & documentation. Free hosting of CPS groupware: http://www.objectis.org. From jkeating at j2solutions.net Tue Dec 6 18:32:09 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 06 Dec 2005 13:32:09 -0500 Subject: yum plugin suggestion or yum change? In-Reply-To: <4395D607.7080002@laposte.net> References: <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> <43947D1C.6030704@insitesinc.com> <604aa7910512051021q35bd94ai59316ea025c0ab7a@mail.gmail.com> <439494CC.3010502@laposte.net> <604aa7910512051243g66f1394cg5e805f91daea620b@mail.gmail.com> <4394BBE9.6010009@laposte.net> <604aa7910512051420s4a6e1c11o1065d400adcd4612@mail.gmail.com> <4394C2A3.1090602@laposte.net> <4395AE7F.7000001@cornell.edu> <1133883303.11387.11.camel@cutter> <4395C28E.2060103@wowway.com> <4395D607.7080002@laposte.net> Message-ID: <1133893930.4302.3.camel@localhost.localdomain> On Tue, 2005-12-06 at 19:18 +0100, Nicolas Mailhot wrote: > There wouldn't have been any "bickering" in the first place if instead > of insisting partial updates were the wrong thing to do people had > admitted at once the real problem was lack of coders. There's no shame > in saying you have no time/you're not interested in doing something. > OTOH when you trumpet formal opposition to something, do expect people > to argue with you. Asking somebody to code it up isn't saying that it is right. However what we think is right shouldn't prevent others from producing code to do it anyway. Users can make their own choice. Yum developers have made the choice by not putting code for it in yum itself. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From mattdm at mattdm.org Tue Dec 6 18:52:28 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 6 Dec 2005 13:52:28 -0500 Subject: yum annoyances In-Reply-To: <604aa7910512060922k33bfcb9bv19e4ae157de470e4@mail.gmail.com> References: <200512061058.38491.czar@czarc.net> <20051206164847.GA7926@jadzia.bu.edu> <604aa7910512060922k33bfcb9bv19e4ae157de470e4@mail.gmail.com> Message-ID: <20051206185228.GA12608@jadzia.bu.edu> On Tue, Dec 06, 2005 at 12:22:22PM -0500, Jeff Spaleta wrote: > > This could be worked around with an "obsolete-packages" rpm in the > > repository, which would mark as Obsolete all such known packages. > Is that really appropriate? To unleash a package in a repository that > will remove functionality from a client system? What happens to user > who were relying on that functionality? Well, if they're using Rawhide, they should by definition not be relying on anything. And in a stable release, this shouldn't happen except between releases (where it often does). > Its one thing to obsolete because of a package name change where the > new package provides similar functionality. Its quite another when > obsoleting is used in a blank payload package to delibrately remove > another package without actually providing similar functionality. Also, the obsoletes tags in such a package would need to precise, so they match the version-release of the latest Core/Extras package but not beyond that, so that there wouldn't be a problem with other repos providing the same package. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Tue Dec 6 18:56:31 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 6 Dec 2005 13:56:31 -0500 Subject: yum annoyances In-Reply-To: <604aa7910512061022g2444dbedve51d2dc2d3a4d33e@mail.gmail.com> References: <604aa7910512060922k33bfcb9bv19e4ae157de470e4@mail.gmail.com> <20051206173015.54829.qmail@web51506.mail.yahoo.com> <604aa7910512061022g2444dbedve51d2dc2d3a4d33e@mail.gmail.com> Message-ID: <20051206185631.GB12608@jadzia.bu.edu> On Tue, Dec 06, 2005 at 01:22:50PM -0500, Jeff Spaleta wrote: > > Seems like an answer might be to have a "check-retired" command. When > > packages are removed from the repo, they are moved to an area where the > > retired packages live. Meta-data is built from that directory so there > > are no typos. > They are moved to an area where retired packages live? So the master > repository server could never actually fully delete the last version > of a particular package? I guess theoretically you could just keep the metadata. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From mattdm at mattdm.org Tue Dec 6 18:57:32 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 6 Dec 2005 13:57:32 -0500 Subject: yum annoyances In-Reply-To: <1133893121.11387.27.camel@cutter> References: <20051206173015.54829.qmail@web51506.mail.yahoo.com> <1133893121.11387.27.camel@cutter> Message-ID: <20051206185732.GC12608@jadzia.bu.edu> On Tue, Dec 06, 2005 at 01:18:41PM -0500, seth vidal wrote: > > Seems like an answer might be to have a "check-retired" command. When > > packages are removed from the repo, they are moved to an area where the > > retired packages live. Meta-data is built from that directory so there > > are no typos. Check-retired would not automatically delete packages just > > like update doesn't automatically update packages. It should print the > > list for approval and proceed only if the user tells it to. > sounds like something worth adding to package-cleanup in yum-utils. Hmmm. Also, this'd be a case of needing to tag a repo as being "special" in some way. Kind of like the thing with source packages.... -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From j.w.r.degoede at hhs.nl Tue Dec 6 19:24:13 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Tue, 06 Dec 2005 20:24:13 +0100 Subject: yum annoyances In-Reply-To: <1133885568.11387.19.camel@cutter> References: <200512061058.38491.czar@czarc.net> <20051206160959.GA6117@ryoko.camperquake.de> <1133885568.11387.19.camel@cutter> Message-ID: <4395E55D.3000707@hhs.nl> seth vidal wrote: > On Tue, 2005-12-06 at 17:09 +0100, Ralf Ertzinger wrote: >> On Tue, Dec 06, 2005 at 10:58:38AM -0500, Gene C. wrote: >> >>> Would it be possible to have some metadata which would flag to yum that the >>> package needs to be removed. >> yum does not know if you want the package removed or not. But it could >> indicate that none of the repos used for this resolver run provides >> this package or a package which obsoletes it. > > > yum list extras. > > -sv > > I think that what Gene / Ralf mean/want (at least this is what I would like) is that if: -this is a default yum upgrade run (iow no --enablerepo or disable) -none of the repos used for this resolver run provides this package -this package causes a conflict, for example has dependcies which were met before the update but not after if we would continue. That then and only then, (normal upgrade, troubel package not in any repo) yum would suggest/ask the user to remove this package. This question should ignore -y, and be skipped when run non interactivly! Maybe this can be done in a plugin? Regards, Hans p.s. I think we can come up with more cases where it would be nice if yum would suggest a fix. Note though that the current default behavior of bombing out of anything is wrong is excellent, yum should _never_ try to fix things automatically like smartpm tries to. From jspaleta at gmail.com Tue Dec 6 19:23:29 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 6 Dec 2005 14:23:29 -0500 Subject: yum annoyances In-Reply-To: <20051206185228.GA12608@jadzia.bu.edu> References: <200512061058.38491.czar@czarc.net> <20051206164847.GA7926@jadzia.bu.edu> <604aa7910512060922k33bfcb9bv19e4ae157de470e4@mail.gmail.com> <20051206185228.GA12608@jadzia.bu.edu> Message-ID: <604aa7910512061123s7f608729q16b9e5af27f48467@mail.gmail.com> On 12/6/05, Matthew Miller wrote: > Also, the obsoletes tags in such a package would need to precise, so they > match the version-release of the latest Core/Extras package but not beyond > that, so that there wouldn't be a problem with other repos providing the > same package. I think you missed my point. Is it appropriate to make functionality "disappear" on a client system via update packages that serve no purpose other than to obsolete other packages? Package foo in core provides /usr/bin/foo which can be scripted in bash scripts. Core decides to remove package foo in fc5 and it has not been added to Extras yet. The foo package from fc4 has no unfullfilled deps which prevent it from installing and running on an fc5 system. Why should an fc4 user who is relying on the functionality provided by package foo be forced to remove that package via the payload-less obsoletes package? We aren't talking about packages that have changed names or sub-packages that have been re-structured. We are talking about packages that have no functional replacement yet in the available Fedora repos. Why should an update/upgrade force the removal of such packages and functionality on client systems? Isn't this situation a case-by-case determination for the local admin? -jef From mattdm at mattdm.org Tue Dec 6 19:35:51 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 6 Dec 2005 14:35:51 -0500 Subject: yum annoyances In-Reply-To: <604aa7910512061123s7f608729q16b9e5af27f48467@mail.gmail.com> References: <200512061058.38491.czar@czarc.net> <20051206164847.GA7926@jadzia.bu.edu> <604aa7910512060922k33bfcb9bv19e4ae157de470e4@mail.gmail.com> <20051206185228.GA12608@jadzia.bu.edu> <604aa7910512061123s7f608729q16b9e5af27f48467@mail.gmail.com> Message-ID: <20051206193551.GA14771@jadzia.bu.edu> On Tue, Dec 06, 2005 at 02:23:29PM -0500, Jeff Spaleta wrote: > > Also, the obsoletes tags in such a package would need to precise, so they > > match the version-release of the latest Core/Extras package but not beyond > > that, so that there wouldn't be a problem with other repos providing the > > same package. > I think you missed my point. Is it appropriate to make functionality > "disappear" on a client system via update packages that serve no > purpose other than to obsolete other packages? I agree with you that this shouldn't happen in updates to released versions of Fedora. > Package foo in core provides /usr/bin/foo which can be scripted in > bash scripts. Core decides to remove package foo in fc5 and it has not > been added to Extras yet. If it's known that package is going to be added to extras at some point soon, that package probably shouldn't be added to the obsoleted-packages list. > The foo package from fc4 has no unfullfilled > deps which prevent it from installing and running on an fc5 system. I'm more concerned about the ones that do have broken deps, which seems to be a lot of the time in cases like this. > Why should an fc4 user who is relying on the functionality provided by > package foo be forced to remove that package via the payload-less > obsoletes package? We aren't talking about packages that have changed > names or sub-packages that have been re-structured. We are talking > about packages that have no functional replacement yet in the > available Fedora repos. Why should an update/upgrade force the removal > of such packages and functionality on client systems? Isn't this > situation a case-by-case determination for the local admin? It still could be; the obsoletes-packages RPM would just be a tool to help if you decide to go that way. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jspaleta at gmail.com Tue Dec 6 20:42:07 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 6 Dec 2005 15:42:07 -0500 Subject: yum annoyances In-Reply-To: <20051206193551.GA14771@jadzia.bu.edu> References: <200512061058.38491.czar@czarc.net> <20051206164847.GA7926@jadzia.bu.edu> <604aa7910512060922k33bfcb9bv19e4ae157de470e4@mail.gmail.com> <20051206185228.GA12608@jadzia.bu.edu> <604aa7910512061123s7f608729q16b9e5af27f48467@mail.gmail.com> <20051206193551.GA14771@jadzia.bu.edu> Message-ID: <604aa7910512061242y5525b003o98fef392d682d195@mail.gmail.com> On 12/6/05, Matthew Miller wrote: > I agree with you that this shouldn't happen in updates to released versions > of Fedora. > If it's known that package is going to be added to extras at some point > soon, that package probably shouldn't be added to the obsoleted-packages > list. As soon as we get that read-the-future plugin into the Extras buildsystem. As an exercise for the reader... how many dropped packages in FC4 that were in FC3 were submitted for review before FC4 release? How many were submitted after FC4 release? > I'm more concerned about the ones that do have broken deps, which seems to > be a lot of the time in cases like this. If installed packages have broken deps.... hasn't anaconda in the past advised you of this as part of the install? fc5t1 anaconda doesn't count since its clearly not representative of full anaconda functionality. I don't see why this is a concern unless anaconda is going to start handling upgrade situation differently. > It still could be; the obsoletes-packages RPM would just be a tool to help > if you decide to go that way. If you install obsoletes-packages... there is no decision point. If obsoleteing is active in the transaction, it obsoletes all the packages that is set to obsolete.. like all other obsoletes in all other packages. For this package to be a tool to help you "decide", it would have to be treated differently than all other obsoletes in all other packages which obsolete without user interaction. Are you know suggesting that this mythical obsoletes-package be treated specially by the tools? -jef From mattdm at mattdm.org Tue Dec 6 20:53:07 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Tue, 6 Dec 2005 15:53:07 -0500 Subject: yum annoyances In-Reply-To: <604aa7910512061242y5525b003o98fef392d682d195@mail.gmail.com> References: <200512061058.38491.czar@czarc.net> <20051206164847.GA7926@jadzia.bu.edu> <604aa7910512060922k33bfcb9bv19e4ae157de470e4@mail.gmail.com> <20051206185228.GA12608@jadzia.bu.edu> <604aa7910512061123s7f608729q16b9e5af27f48467@mail.gmail.com> <20051206193551.GA14771@jadzia.bu.edu> <604aa7910512061242y5525b003o98fef392d682d195@mail.gmail.com> Message-ID: <20051206205307.GA19639@jadzia.bu.edu> On Tue, Dec 06, 2005 at 03:42:07PM -0500, Jeff Spaleta wrote: > > If it's known that package is going to be added to extras at some point > > soon, that package probably shouldn't be added to the obsoleted-packages > > list. > As soon as we get that read-the-future plugin into the Extras > buildsystem. As an exercise for the reader... how many dropped Either that or the "better coordination between core and extras" plugin. > packages in FC4 that were in FC3 were submitted for review before FC4 > release? How many were submitted after FC4 release? Early-growth time for extras; not really a benchmark for normal future operation -- or at least, I hope not. > > I'm more concerned about the ones that do have broken deps, which seems to > > be a lot of the time in cases like this. > If installed packages have broken deps.... hasn't anaconda in the past > advised you of this as part of the install? fc5t1 anaconda doesn't If I remember right, the pre-anaconda installer did, and would make you pick "proceed anyway". Anaconda, however, just spits out some warnings to one of the text consoles and goes on its merry way. FC5t1 doesn't count since it doesn't do upgrades at all. :) > count since its clearly not representative of full anaconda > functionality. I don't see why this is a concern unless anaconda is > going to start handling upgrade situation differently. Well, it's a concern because currently, upgraded systems accumulate cruft.a > > It still could be; the obsoletes-packages RPM would just be a tool to > > help if you decide to go that way. > If you install obsoletes-packages... there is no decision point. If > obsoleteing is active in the transaction, it obsoletes all the > packages that is set to obsolete.. like all other obsoletes in all > other packages. For this package to be a tool to help you "decide", it > would have to be treated differently than all other obsoletes in all > other packages which obsolete without user interaction. Are you know > suggesting that this mythical obsoletes-package be treated specially > by the tools? Anaconda certainly treats a lot of packages specially. And if an admin wants to prevent this from happening, he or she could add it to the list of packages yum ignores. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From jspaleta at gmail.com Tue Dec 6 21:13:29 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 6 Dec 2005 16:13:29 -0500 Subject: yum annoyances In-Reply-To: <20051206205307.GA19639@jadzia.bu.edu> References: <200512061058.38491.czar@czarc.net> <20051206164847.GA7926@jadzia.bu.edu> <604aa7910512060922k33bfcb9bv19e4ae157de470e4@mail.gmail.com> <20051206185228.GA12608@jadzia.bu.edu> <604aa7910512061123s7f608729q16b9e5af27f48467@mail.gmail.com> <20051206193551.GA14771@jadzia.bu.edu> <604aa7910512061242y5525b003o98fef392d682d195@mail.gmail.com> <20051206205307.GA19639@jadzia.bu.edu> Message-ID: <604aa7910512061313j51d35575i86f8a70eb4961b82@mail.gmail.com> On 12/6/05, Matthew Miller wrote: > Anaconda certainly treats a lot of packages specially. And if an admin > wants to prevent this from happening, he or she could add it to the list of > packages yum ignores. Or conversely, the admin can clean out cruft manually. It would take a rather large effort to know everything this catchall package is going to do before it does it... to know whether or not it should be excluded. Sorry, your arguments have not convinced me automating cruft removal using a single payload-less catchall package via obsolete is appropriate for default behavior. I'd prefer if obsoletes were used as sparingly as possible in this way and instead they be used primarily for situations where packaging has changed but equivalent functionality is still provided. I'd rather see a focus on admin tools to notify that the packages are no longer part of the repos they have enabled and let admins make decisions on a case-by-case package-by-package basis without incurring loss of functionality whenever possible. -jef From msw at rpath.com Tue Dec 6 21:59:50 2005 From: msw at rpath.com (Matt Wilson) Date: Tue, 6 Dec 2005 16:59:50 -0500 Subject: yum annoyances In-Reply-To: <604aa7910512060922k33bfcb9bv19e4ae157de470e4@mail.gmail.com> References: <200512061058.38491.czar@czarc.net> <20051206164847.GA7926@jadzia.bu.edu> <604aa7910512060922k33bfcb9bv19e4ae157de470e4@mail.gmail.com> Message-ID: <20051206215950.GB25435@rpath.com> On Tue, Dec 06, 2005 at 12:22:22PM -0500, Jeff Spaleta wrote: > On 12/6/05, Matthew Miller wrote: > > This could be worked around with an "obsolete-packages" rpm in the > > repository, which would mark as Obsolete all such known packages. > > Is that really appropriate? To unleash a package in a repository that > will remove functionality from a client system? What happens to user > who were relying on that functionality? Let me outline how this works in a Conary world[1]. The distribution is defined by a hierarchical set of groups. When a package is replaced by another package, we build a special "redirect" in the repository that moves you from one package to the other. The classical example of this is a migration from kbd to consoletools to kbd. This is somewhat similar to Obsoletes. When it comes time to put a package out to pasture (that is, remove it from the distribution altogether, when there is nothing that assumes the functionality of the package), we just remove it from the group. When the user updates to the new version of the group, the removal of the package from the group is applied to the system (that is, the package is removed from the systeM). If the user depends on the package, they can "pin" it on the system and it won't be removed. The interactive frontend can help guide users though the changes that are going to be made by performing an update. At that point, a user could decide to pin the package instead of allowing it to be removed. You may be able to apply this methodology to yum. What do you think? [1] Yes, I know everyone was dying to know! Cheers, Matt -- Matt Wilson rPath, Inc. msw at rpath.com From skvidal at phy.duke.edu Tue Dec 6 22:05:03 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Tue, 06 Dec 2005 17:05:03 -0500 Subject: yum annoyances In-Reply-To: <20051206215950.GB25435@rpath.com> References: <200512061058.38491.czar@czarc.net> <20051206164847.GA7926@jadzia.bu.edu> <604aa7910512060922k33bfcb9bv19e4ae157de470e4@mail.gmail.com> <20051206215950.GB25435@rpath.com> Message-ID: <1133906703.11387.58.camel@cutter> > The interactive frontend can help guide users though the changes that > are going to be made by performing an update. At that point, a user > could decide to pin the package instead of allowing it to be removed. and for a non-interactive run of conary? What happens on the automated runs? -sv From msw at rpath.com Tue Dec 6 22:22:52 2005 From: msw at rpath.com (Matt Wilson) Date: Tue, 6 Dec 2005 17:22:52 -0500 Subject: yum annoyances In-Reply-To: <1133906703.11387.58.camel@cutter> References: <200512061058.38491.czar@czarc.net> <20051206164847.GA7926@jadzia.bu.edu> <604aa7910512060922k33bfcb9bv19e4ae157de470e4@mail.gmail.com> <20051206215950.GB25435@rpath.com> <1133906703.11387.58.camel@cutter> Message-ID: <20051206222252.GC25435@rpath.com> On Tue, Dec 06, 2005 at 05:05:03PM -0500, seth vidal wrote: > > > The interactive frontend can help guide users though the changes that > > are going to be made by performing an update. At that point, a user > > could decide to pin the package instead of allowing it to be removed. > > and for a non-interactive run of conary? What happens on the automated > runs? By default, the package will be removed if it was removed from a group that you have installed and it wasn't added to any other group you have installed -- _unless_ it creates a dependency problem. So, we're not removing important deprecated shared libraries that are needed by other things on the system. Our philosophy for the automated case is to do the thing that most people want by default. In this case we believe that it's better to be closer to the next version of the OS than it is to leave old packages littered around forever. We give the user two ways to rely on deprecated packages (1. pin them and 2. rely on dependencies to keep the system in a working state, even if it requires an old package) and we have rollback functionality that can be used to go back to the older state. That makes cleaning up old packages seem pretty safe to me. If removing packages seems a little to drastic, you can set up the groups in Conary one more way. You can create group-dist-deprecated, and add all of the obsoleted packages to that group with the default flag set to False. Users that have an affinity to old software can install group-dist-deprecated. When you remove something from the distribution (which is group-dist in our case), you would add it to group-dist-deprecated. If the user had group-dist-deprecated installed, the package won't be removed from the system. Cheers, Matt -- Matt Wilson rPath, Inc. msw at rpath.com From rodd at clarkson.id.au Tue Dec 6 22:30:11 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Wed, 07 Dec 2005 09:30:11 +1100 Subject: Yum bug? In-Reply-To: <4395AD9F.7070700@conversis.de> References: <4394B78C.6050009@conversis.de> <604aa7910512051400g741b73fejfb18ab73a811a350@mail.gmail.com> <1133837283.3762.15.camel@localhost.localdomain> <4395AD9F.7070700@conversis.de> Message-ID: <1133908211.3083.0.camel@localhost.localdomain> On Tue, 2005-12-06 at 16:26 +0100, Dennis Jacobfeuerborn wrote: > > Rodd Clarkson wrote: > > On Mon, 2005-12-05 at 17:00 -0500, Jeff Spaleta wrote: > >> On 12/5/05, Dennis Jacobfeuerborn wrote: > >>> Not sure if I should file a bug or if I'm doing something wrong on my end? > >> bug already reported to the lists repeatedly, and reported in bugzilla > >> and the fix should be in rawhide "soon" since the fc4 test update > >> that fixes this already exists. > >> > >> work-around for now remove all the files named "cachecookie" in your > >> /var/cache/yum tree > >> or wait 8 hours for the cookies to expire. > > > > jef, > > > > I know you're trying to help (and your help is appreciated), but at this > > point, it's probably better to just respond to these messages with > > 'solution already discussed' and 'search the archives'. > > > > This forces the individual asking the question to learn how to search > > the archives, rather than just asking. > > > > Personally, I'm sick of the number of times this question has been > > asked. Seriously fed up. I'm a patient person, and I don't mind a > > little repetition, but in this case the solution exists in a number of > > emails both on test-list and devel-list and the problem is related to > > the basic update mechanism for fedora - yum, so in my opinion, this is > > something that everyone on the list should just read. Yum is (like it > > or not) core funcationality for fedora, so if you're not paying > > attention to what's happening to yum, or kernels, or the likes then you > > don't get to ask the same question for the 20th time. > > > > Sorry if this is a little harsh, but we're about to get back into test > > releases which means having people ask the same questions over and over > > and over (etc) because it's easier than actually reading the list they > > are subscribed to, or searching the archives. > > > > > > R. > > > > Look, I searched on both bugzilla and in the devel archives. I failed to > see the bug in bugzilla, my bad, I'm an idiot. However I do read the devel > list daily and cannot remember reading anything about this problem. > Searching for "repomd.xml" lists exactly two mails as of now, my own and > one reply. Searching for "cachecookie" (once you actually now this has > something to do with "cachecookie") lists three mails, two replies to this > thread and the latest rawhide report showing that this was fixed. > I tried to find, failed, and will now accept my shame and commit seppuku. > > Having said that I think on a public mailing-list you will simply have to > live with the imperfection of human beeings. I promise I'll search more > thoroughly the next time but even then I cannot provide you with a > guarantee that I will always be successfull. While I see that this kind of > stuff can be annoying I cannot understand why someone can get so wound up > about it. It was just a mail. > > Sorry, > Dennis Mea Culpa. I was having a bad day yesterday and I just flipped a little. I'm usually more patient. sorry. Rodd -- "It's a fine line between denial and faith. It's much better on my side" From wrrhdev at riede.org Wed Dec 7 02:59:47 2005 From: wrrhdev at riede.org (Willem Riede) Date: Wed, 07 Dec 2005 02:59:47 +0000 Subject: Dovecot 1.0 In-Reply-To: <43958248.40509@reub.net> (from reuben-fedora-devel@reub.net on Tue Dec 6 07:21:28 2005) References: <1133705505l.3795l.0l@serve.riede.org> <43938738.3090906@develer.com> <43958248.40509@reub.net> Message-ID: <1133924387l.19184l.1l@serve.riede.org> On 12/06/2005 07:21:28 AM, Reuben Farrelly wrote: > > On 5/12/2005 1:18 p.m., Bernardo Innocenti wrote: >> Willem Riede wrote: >> >>> Can we have dovecot 1.0 alpha4 in FC5? Even though the word alpha is >>> present in the version, it is quite stable, and fixes many problems that >>> there are in 0.99.14. As a matter of fact, there is no upstream support >>> for 0.99.x. Any reports are met with 'please upgrade and your problem >>> will likely be over'. >> >> Yes, please! I was waiting for Dovecot 1.0 to switch to Dovecot >> from courier-imap without anyone noticing the difference. >> >> The feature I'm missing in 0.99 is namespaces. Without this, >> I'd have to reconfigure all the MUAs to change their IMAP >> prefix from "INBOX" to "" (empty string). > > I would like to add my +1 to this as well. Dovecot-0.99.x is arguably just > as bad if not more 'alpha' than the upcoming 1.0 releases both in terms of > bugs and of features and it seems most odd to be shipping a package that > isn't supported by the upstream developer and community. I would also put > the case that 0.99.x was more 'alpha' in it's quality than the current > releases that are actually labelled as 'alpha'. > > Anyway, there is a bugzilla entry open as an RFE for it: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=170960 > > Perhaps that might be a good place to start adding comments, maybe if enough > people ask nicely in there and show support, it might happen from within RH > ;-) I have added the 1.0-alpha4 spec file and the patches I successfully used myself to run dovecot-1.0-alpha4 on fc5t1 to that bugzilla, so I hope somebody makes use of those and upgrades dovecot in devel - please? pretty please? :-) Thanks, Willem Riede. From bojan at rexursive.com Wed Dec 7 03:27:12 2005 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 07 Dec 2005 14:27:12 +1100 Subject: Dovecot 1.0 Message-ID: <20051207142712.d88cha0kgkc0g4cs@imp.rexursive.com> Yep, that would be nice. It seems that Evo 2.4.x and Dovecot may have some interoperability issue that were addressed in 1.0. -- Bojan From sundaram at redhat.com Wed Dec 7 07:56:47 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 07 Dec 2005 13:26:47 +0530 Subject: yum annoyances In-Reply-To: <20051206222252.GC25435@rpath.com> References: <200512061058.38491.czar@czarc.net> <20051206164847.GA7926@jadzia.bu.edu> <604aa7910512060922k33bfcb9bv19e4ae157de470e4@mail.gmail.com> <20051206215950.GB25435@rpath.com> <1133906703.11387.58.camel@cutter> <20051206222252.GC25435@rpath.com> Message-ID: <439695BF.5060107@redhat.com> Hi >If removing packages seems a little to drastic, you can set up the >groups in Conary one more way. You can create group-dist-deprecated, >and add all of the obsoleted packages to that group with the default >flag set to False. Users that have an affinity to old software can >install group-dist-deprecated. When you remove something from the >distribution (which is group-dist in our case), you would add it to >group-dist-deprecated. If the user had group-dist-deprecated >installed, the package won't be removed from the system. > > There is already a yum group for providing compatibility libs for legacy software. This solution looks is consistent with the usage of yum group in favor of virtual packages in Fedora. It is also more flexible. regards Rahul From pmatilai at laiskiainen.org Wed Dec 7 09:02:34 2005 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Wed, 7 Dec 2005 01:02:34 -0800 (PST) Subject: yum plugin suggestion or yum change? In-Reply-To: <1133893470.11387.29.camel@cutter> References: <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> <43947D1C.6030704@insitesinc.com> <604aa7910512051021q35bd94ai59316ea025c0ab7a@mail.gmail.com> <439494CC.3010502@laposte.net> <604aa7910512051243g66f1394cg5e805f91daea620b@mail.gmail.com> <4394BBE9.6010009@laposte.net> <604aa7910512051420s4a6e1c11o1065d400adcd4612@mail.gmail.com> <4394C2A3.1090602@laposte.net> <4395AE7F.7000001@cornell.edu> <1133883303.11387.11.camel@cutter> <4395C28E.2060103@wowway.com> <4395D607.7080002@laposte.net> <1133893470.11387.29.camel@cutter> Message-ID: On Tue, 6 Dec 2005, seth vidal wrote: > I'm still not convinced that partial updates are an okay thing to do. > But someone providing sensible code that handles the ugly corner cases > nicely will do a lot toward convincing me. Just a FYI for anybody starting to play with this: This can't be done with current yum plugin infrastructure - plugins in pre/postresolve slots can't affect the result code yum itself sees from the depsolve stage, meaning even if you fix the transaction set from postresolve yum will still stop with broken deps errors. So, it's possible to write a proof-of-concept plugin for this but it wont be able to do anything without some changes to yum itself. - Panu - From buildsys at redhat.com Wed Dec 7 11:11:44 2005 From: buildsys at redhat.com (Build System) Date: Wed, 7 Dec 2005 06:11:44 -0500 Subject: rawhide report: 20051207 changes Message-ID: <200512071111.jB7BBiXL026956@porkchop.devel.redhat.com> Removed package mod_jk Updated Packages: acl-2.2.32-2.1 -------------- * Tue Dec 06 2005 Thomas Woerner 2.2.32-2.1 - fixed permissions of libacl * Tue Dec 06 2005 Thomas Woerner 2.2.32-2 - spec file cleanup - mark po files as lang specific apr-1.2.2-2 ----------- * Tue Dec 06 2005 Joe Orton 1.2.2-2 - avoid linking against -lrt - don't print -L${libdir} in --libs output - don't export -lcrypt/-luuid in .la file apr-util-1.2.2-2 ---------------- * Tue Dec 06 2005 Joe Orton 1.2.2-2 - trim exports from .la file/--libs output (#174924) attr-2.4.24-2 ------------- * Tue Dec 06 2005 Thomas Woerner 2.4.24-2 - spec file cleanup - mark po files as lang specific bash-3.0-38 ----------- * Tue Dec 06 2005 Tim Waugh 3.0-38 - Test out improved sighandler patch (bug #169231). ethereal-0.10.13-6 ------------------ * Tue Dec 06 2005 Radek Vokal 0.10.13-6 - libselinux build dependency added evolution-data-server-1.5.2-1 ----------------------------- * Tue Dec 06 2005 David Malcolm - 1.5.2-1 - 1.5.2 - bump eds_base_version from 1.4 to 1.6 - updated patch 102 gtkhtml3-3.9.2-1 ---------------- * Tue Dec 06 2005 David Malcolm - 3.9.2-1 - 3.9.2 gtksourceview-1.5.1-2 --------------------- * Tue Dec 06 2005 Dan Williams - 1.5.1-2 - Fix off-by-one when searching for language specification files which breaks syntax hilighting. Already fixed upstream. k3b-0:0.12.8-1 -------------- * Tue Dec 06 2005 Harald Hoyer 0:0.12.8-1 - version 0.12.8 kdeartwork-3.5.0-1 ------------------ * Tue Nov 29 2005 Than Ngo 3.5.0-1 - 3.5 final kdebindings-3.5.0-1 ------------------- * Tue Nov 29 2005 Than Ngo 3.5.0-1 - 3.5 final less-394-1 ---------- * Tue Dec 06 2005 Jindrich Novy 394-1 - update to less-394 libsemanage-1.3.64-1 -------------------- * Tue Dec 06 2005 Dan Walsh 1.3.64-1 - Upgrade to latest from NSA * Changed semanage_handle_create() to set do_reload based on is_selinux_enabled(). This prevents improper attempts to load policy on a non-SELinux system. * Mon Dec 05 2005 Dan Walsh 1.3.63-1 - Upgrade to latest from NSA * Dropped handle from user_del_role interface. * Removed defrole interfaces. mc-1:4.6.1a-5 ------------- * Tue Dec 06 2005 Jindrich Novy 4.6.1a-5 - correctly concatenate directory and file in concat_dir_and_file() - highlight PHP files correctly (#174802) - use evince instead of gv to view ps files - align mini status bar with main panels nc-1.84-2 --------- * Wed Dec 07 2005 Radek Vokal 1.84-2 - fix build requires * Fri Nov 18 2005 Radek Vokal 1.84-1 - follow upstream * Fri Oct 21 2005 Radek Vokal 1.82-2 - use SO_REUSEADDR (#171315) php-pear-1:1.4.5-4 ------------------ * Tue Dec 06 2005 Joe Orton 1:1.4.5-4 - fix virtual provide for PEAR package (#175074) policycoreutils-1.27.36-2 ------------------------- * Tue Dec 06 2005 Dan Walsh 1.27.36-2 - Require new version of libsemanage scim-tables-0.5.5-1 ------------------- * Wed Dec 07 2005 Jens Petersen - 0.5.5-1 - 0.5.5 release - update filelist selinux-policy-2.0.11-1 ----------------------- * Tue Dec 06 2005 Dan Walsh 2.0.11-1. Update from upstream squid-7:2.5.STABLE12-2 ---------------------- * Mon Nov 28 2005 Martin Stransky 7:2.5.STABLE12-2 - rewriten patch squid-2.5.STABLE10-64bit.patch, it works with "--with-large-files" option now - fix for #72896 - squid does not support > 1024 file descriptors, new "--enable-fd-config" option for it. udev-076-1 ---------- * Tue Dec 06 2005 Harald Hoyer - 076-1 - speedup udevd with selinux by calling matchpathcon_init_prefix() - version 076 vnc-4.1.1-28 ------------ * Tue Dec 06 2005 Tim Waugh 4.1.1-28 - Enable all the extensions, which were accidentally disabled. * Tue Dec 06 2005 Tim Waugh 4.1.1-27 - Fix 64-bit server (bug #174702). - Build requires freetype-devel. - Build requires libXext-devel, libXtst-devel, automake, libtool, pkgconfig, libfontenc-devel, xorg-x11-util-macros. xorg-x11-proto-devel-0.99.3-1 ----------------------------- * Wed Dec 07 2005 Mike A. Harris 0.99.3-1 - Update to printproto-1.0.2, trapproto-3.4.2, xproto-7.0.3 from the X11R7 RC3 release. xorg-x11-util-macros-0.99.2-1 ----------------------------- yum-2.4.1-3 ----------- * Tue Dec 06 2005 Jeremy Katz - 2.4.1-3 - ... and actually apply the patch Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel = 0:2.6.14-1.1696_FC5 cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5smp cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel = 0:2.6.14-1.1696_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 Broken deps for ia64 ---------------------------------------------------------- rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 Broken deps for s390 ---------------------------------------------------------- rhythmbox - 0.9.1-1.s390 requires libdbus-1.so.1 rhythmbox - 0.9.1-1.s390 requires libdbus-glib-1.so.1 Broken deps for s390x ---------------------------------------------------------- rhythmbox - 0.9.1-1.s390x requires libdbus-1.so.1()(64bit) rhythmbox - 0.9.1-1.s390x requires libdbus-glib-1.so.1()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 From tmus at tmus.dk Wed Dec 7 12:51:39 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Wed, 07 Dec 2005 13:51:39 +0100 Subject: yum plugin suggestion or yum change? In-Reply-To: References: <43944725.6050000@redhat.com> <604aa7910512050642h38885968g995c0f6b10e655f2@mail.gmail.com> <604aa7910512050817k9a341bbja4513a3d2aac0ad1@mail.gmail.com> <43947D1C.6030704@insitesinc.com> <604aa7910512051021q35bd94ai59316ea025c0ab7a@mail.gmail.com> <439494CC.3010502@laposte.net> <604aa7910512051243g66f1394cg5e805f91daea620b@mail.gmail.com> <4394BBE9.6010009@laposte.net> <604aa7910512051420s4a6e1c11o1065d400adcd4612@mail.gmail.com> <4394C2A3.1090602@laposte.net> <4395AE7F.7000001@cornell.edu> <1133883303.11387.11.camel@cutter> <4395C28E.2060103@wowway.com> <4395D607.7080002@laposte.net> <1133893470.11387.29.camel@cutter> Message-ID: Panu Matilainen wrote: > On Tue, 6 Dec 2005, seth vidal wrote: >> I'm still not convinced that partial updates are an okay thing to do. >> But someone providing sensible code that handles the ugly corner cases >> nicely will do a lot toward convincing me. > > Just a FYI for anybody starting to play with this: > > This can't be done with current yum plugin infrastructure - plugins in > pre/postresolve slots can't affect the result code yum itself sees from > the depsolve stage, meaning even if you fix the transaction set from > postresolve yum will still stop with broken deps errors. So, it's > possible to write a proof-of-concept plugin for this but it wont be able > to do anything without some changes to yum itself. > > - Panu - > Very interesting - I was looking for something like that :o) /Thomas From dimi at lattica.com Wed Dec 7 14:00:48 2005 From: dimi at lattica.com (Dimi Paun) Date: Wed, 7 Dec 2005 09:00:48 -0500 Subject: rawhide report: 20051207 changes References: <200512071111.jB7BBiXL026956@porkchop.devel.redhat.com> Message-ID: <01d801c5fb36$a8d1e1a0$b6491b31@td612671> From: "Build System" > Removed package mod_jk Last time I've checked this was the recommended plugin on Tomcat's webpage. mod_proxy_ajp instead? -- Dimi Paun Lattica, Inc. From gilboada at netvision.net.il Wed Dec 7 14:01:07 2005 From: gilboada at netvision.net.il (Gilboa Davara) Date: Wed, 07 Dec 2005 16:01:07 +0200 Subject: Upgrade between FC5 test releases. Message-ID: <1133964067.16189.15.camel@gilboa-work-dev> Hello all, Stupid question: Will it be possible to upgrade between different FC5 test releases using yum/anaconda/DVD/what-ever? Having to reinstall and reconfigure everything with each test release (including the official FC5) puts a big dent into my (and I assume other's) ability to contribute to the FC's pre-release bug hunting. Gilboa From jspaleta at gmail.com Wed Dec 7 14:12:05 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 7 Dec 2005 09:12:05 -0500 Subject: Upgrade between FC5 test releases. In-Reply-To: <1133964067.16189.15.camel@gilboa-work-dev> References: <1133964067.16189.15.camel@gilboa-work-dev> Message-ID: <604aa7910512070612i4d63dcd5g4da81af53bf724e5@mail.gmail.com> On 12/7/05, Gilboa Davara wrote: > Stupid question: > Will it be possible to upgrade between different FC5 test releases using > yum/anaconda/DVD/what-ever? > Having to reinstall and reconfigure everything with each test release > (including the official FC5) puts a big dent into my (and I assume > other's) ability to contribute to the FC's pre-release bug hunting. Isn't reconfiguring everything and making sure it all works as you expect part of the bug hunting? -jef From sundaram at redhat.com Wed Dec 7 14:18:22 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 07 Dec 2005 19:48:22 +0530 Subject: Upgrade between FC5 test releases. In-Reply-To: <1133964067.16189.15.camel@gilboa-work-dev> References: <1133964067.16189.15.camel@gilboa-work-dev> Message-ID: <4396EF2E.7060808@redhat.com> Gilboa Davara wrote: >Hello all, > >Stupid question: >Will it be possible to upgrade between different FC5 test releases using >yum/anaconda/DVD/what-ever? >Having to reinstall and reconfigure everything with each test release >(including the official FC5) puts a big dent into my (and I assume >other's) ability to contribute to the FC's pre-release bug hunting. > > In general, both Anaconda and yum provides the ability to do that. Fedora Core 5 test 1 doesnt due to the ongoing major changes. You just have to make sure that you can workaround any potential cruft between test releases and report them to the fedora-test list as part of your bug hunting. regards Rahul From jkeating at j2solutions.net Wed Dec 7 14:44:32 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Wed, 07 Dec 2005 09:44:32 -0500 Subject: Upgrade between FC5 test releases. In-Reply-To: <1133964067.16189.15.camel@gilboa-work-dev> References: <1133964067.16189.15.camel@gilboa-work-dev> Message-ID: <1133966672.2883.3.camel@ender> On Wed, 2005-12-07 at 16:01 +0200, Gilboa Davara wrote: > > Stupid question: > Will it be possible to upgrade between different FC5 test releases using > yum/anaconda/DVD/what-ever? > Having to reinstall and reconfigure everything with each test release > (including the official FC5) puts a big dent into my (and I assume > other's) ability to contribute to the FC's pre-release bug hunting. > It is not supported nor recommended. Test releases are not designed to upgrade to anything, and any bug arising out of such actions aren't really going to be looked at to be fixed. If anything, upgrades from various FC4 states to the latest FC5 test release should be tested. This will help the developers understand exactly what they need to do for this supported upgrade path. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From gilboada at netvision.net.il Wed Dec 7 14:59:11 2005 From: gilboada at netvision.net.il (Gilboa Davara) Date: Wed, 07 Dec 2005 16:59:11 +0200 Subject: Upgrade between FC5 test releases. In-Reply-To: <604aa7910512070612i4d63dcd5g4da81af53bf724e5@mail.gmail.com> References: <1133964067.16189.15.camel@gilboa-work-dev> <604aa7910512070612i4d63dcd5g4da81af53bf724e5@mail.gmail.com> Message-ID: <1133967551.16189.18.camel@gilboa-work-dev> On Wed, 2005-12-07 at 09:12 -0500, Jeff Spaleta wrote: > On 12/7/05, Gilboa Davara wrote: > > Stupid question: > > Will it be possible to upgrade between different FC5 test releases using > > yum/anaconda/DVD/what-ever? > > Having to reinstall and reconfigure everything with each test release > > (including the official FC5) puts a big dent into my (and I assume > > other's) ability to contribute to the FC's pre-release bug hunting. > > Isn't reconfiguring everything and making sure it all works as you > expect part of the bug hunting? Umm... I doubt that adding my own ports to /etc/services and updating the smb.conf and exports files is overly beneficial to the test release tests. > > -jef > From gilboada at netvision.net.il Wed Dec 7 15:00:04 2005 From: gilboada at netvision.net.il (Gilboa Davara) Date: Wed, 07 Dec 2005 17:00:04 +0200 Subject: Upgrade between FC5 test releases. In-Reply-To: <1133966672.2883.3.camel@ender> References: <1133964067.16189.15.camel@gilboa-work-dev> <1133966672.2883.3.camel@ender> Message-ID: <1133967604.16189.20.camel@gilboa-work-dev> On Wed, 2005-12-07 at 09:44 -0500, Jesse Keating wrote: > On Wed, 2005-12-07 at 16:01 +0200, Gilboa Davara wrote: > > > > Stupid question: > > Will it be possible to upgrade between different FC5 test releases using > > yum/anaconda/DVD/what-ever? > > Having to reinstall and reconfigure everything with each test release > > (including the official FC5) puts a big dent into my (and I assume > > other's) ability to contribute to the FC's pre-release bug hunting. > > > > It is not supported nor recommended. Test releases are not designed to > upgrade to anything, and any bug arising out of such actions aren't > really going to be looked at to be fixed. If anything, upgrades from > various FC4 states to the latest FC5 test release should be tested. > This will help the developers understand exactly what they need to do > for this supported upgrade path. Ummm... didn't really consider that. Interesting option. Gilboa From jspaleta at gmail.com Wed Dec 7 15:03:10 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 7 Dec 2005 10:03:10 -0500 Subject: Upgrade between FC5 test releases. In-Reply-To: <1133966672.2883.3.camel@ender> References: <1133964067.16189.15.camel@gilboa-work-dev> <1133966672.2883.3.camel@ender> Message-ID: <604aa7910512070703i443c6dfbu90f68381d477374f@mail.gmail.com> On 12/7/05, Jesse Keating wrote: > If anything, upgrades from various FC4 states to the latest > FC5 test release should be tested. > This will help the developers understand exactly what they need to do > for this supported upgrade path. I wish I knew of a good way to get a summary of what obsoletes would fire when update/upgrade from one repository state to another for analysis. repoanalysis --show-obsoleting upgrade fc4-fully-updated-state rawhide-state -jef From skvidal at phy.duke.edu Wed Dec 7 15:09:49 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 07 Dec 2005 10:09:49 -0500 Subject: Upgrade between FC5 test releases. In-Reply-To: <604aa7910512070703i443c6dfbu90f68381d477374f@mail.gmail.com> References: <1133964067.16189.15.camel@gilboa-work-dev> <1133966672.2883.3.camel@ender> <604aa7910512070703i443c6dfbu90f68381d477374f@mail.gmail.com> Message-ID: <1133968189.17715.0.camel@cutter> On Wed, 2005-12-07 at 10:03 -0500, Jeff Spaleta wrote: > On 12/7/05, Jesse Keating wrote: > > If anything, upgrades from various FC4 states to the latest > > FC5 test release should be tested. > > This will help the developers understand exactly what they need to do > > for this supported upgrade path. > > I wish I knew of a good way to get a summary of what obsoletes would > fire when update/upgrade from one repository state to another for > analysis. > > repoanalysis --show-obsoleting upgrade fc4-fully-updated-state rawhide-state yum list obsoletes doesn't do it enough? -sv From jspaleta at gmail.com Wed Dec 7 15:27:53 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 7 Dec 2005 10:27:53 -0500 Subject: Upgrade between FC5 test releases. In-Reply-To: <1133968189.17715.0.camel@cutter> References: <1133964067.16189.15.camel@gilboa-work-dev> <1133966672.2883.3.camel@ender> <604aa7910512070703i443c6dfbu90f68381d477374f@mail.gmail.com> <1133968189.17715.0.camel@cutter> Message-ID: <604aa7910512070727l544adaa8n6b0c7cf0d808ddec@mail.gmail.com> On 12/7/05, seth vidal wrote: > yum list obsoletes doesn't do it enough? doesn't that compare installed state to repospace? I'm wishing for something that wasn't dependant on my installed state where I could take a stab at reviewing what obsoletes get fired from one "repo state" to another just from available repodata regardless of my system install state. Why? As a first cut I could ask questions like "what obsoletes would fire on a system that is fc2+legacy to fc5 upgrade" without having to be on an fc2+legacy system. Or "what are the obsoletes that fire from an everything install of fc4+fe4 upgraded to rawhide today" without having to have a system in the fc4+fe4 everything state to start with. I have no idea if this sort of offline analysis of repodata will reveal any problems, so its hard to judge if its worth the effort to do this sort of offline situational "whatif" testing.. hard to know until I do it. And up to this point, everytime I've come up with a goofball question that I want to ask against repodata, Panu has responded with some sort of tweak to a util in yum-utils. I really blame Panu for continuing to enable me to ask odder and odder questions with repodata. -jef From nicolas.mailhot at laposte.net Wed Dec 7 17:02:11 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 7 Dec 2005 18:02:11 +0100 (CET) Subject: rawhide report: 20051207 changes In-Reply-To: <01d801c5fb36$a8d1e1a0$b6491b31@td612671> References: <200512071111.jB7BBiXL026956@porkchop.devel.redhat.com> <01d801c5fb36$a8d1e1a0$b6491b31@td612671> Message-ID: <27799.192.54.193.25.1133974931.squirrel@rousalka.dyndns.org> On Mer 7 d?cembre 2005 15:00, Dimi Paun wrote: > From: "Build System" >> Removed package mod_jk > > Last time I've checked this was the recommended plugin > on Tomcat's webpage. mod_proxy_ajp instead? Yes Apache 2.2 can do ajp proxying natively now. -- Nicolas Mailhot From orion at cora.nwra.com Wed Dec 7 19:00:26 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Wed, 07 Dec 2005 12:00:26 -0700 Subject: i386 devel packages in x86_64 tree (alsa) Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Is there a particular criteria for which i386 devel packages end up the in the x86_64 tree? Just noting because I need alsa-libs-devel.i386 but it's not there. - -Orion -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDlzFKORnzrtFC2/sRAkcMAJ4rIyAAkduFr3OgCzGduIwhLZVFmQCffLXv 92BaJpLK7TNHohLMknbnX1A= =Lfkg -----END PGP SIGNATURE----- From drepper at redhat.com Wed Dec 7 19:20:16 2005 From: drepper at redhat.com (Ulrich Drepper) Date: Wed, 07 Dec 2005 11:20:16 -0800 Subject: .local/mDNS resolving in FC5 [was Re: Zeroconf in FC5?] In-Reply-To: <1132840347.19458.396.camel@blaa> References: <1117766193.4649.51.camel@ninja> <42A2458C.4030300@redhat.com> <1132840347.19458.396.camel@blaa> Message-ID: <439735F0.8010800@redhat.com> Mark McLoughlin wrote: > At the very least, though, it looks like progress in the direction you > suggested. Yes, it's certainly a step in the right direction. But I don't think we're there yet. At least the last time I looked. Unfortunately I cannot devote any time on investigating this. If somebody is really interested, I think the hardest problems are handled now. So, look at it, analyze it, describe the implementation, fix it up/optimize it. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? From notting at redhat.com Wed Dec 7 19:39:38 2005 From: notting at redhat.com (Bill Nottingham) Date: Wed, 7 Dec 2005 14:39:38 -0500 Subject: i386 devel packages in x86_64 tree (alsa) In-Reply-To: References: Message-ID: <20051207193938.GB15719@devserv.devel.redhat.com> Orion Poplawski (orion at cora.nwra.com) said: > Is there a particular criteria for which i386 devel packages end up the > in the x86_64 tree? Generally, the LSB set. There is discussion of expanding it, but that will require some work. Bill From bgerst at didntduck.org Wed Dec 7 20:05:22 2005 From: bgerst at didntduck.org (Brian Gerst) Date: Wed, 07 Dec 2005 15:05:22 -0500 Subject: i386 devel packages in x86_64 tree (alsa) In-Reply-To: <20051207193938.GB15719@devserv.devel.redhat.com> References: <20051207193938.GB15719@devserv.devel.redhat.com> Message-ID: <43974082.8040507@didntduck.org> Bill Nottingham wrote: > Orion Poplawski (orion at cora.nwra.com) said: > >>Is there a particular criteria for which i386 devel packages end up the >>in the x86_64 tree? > > > Generally, the LSB set. There is discussion of expanding it, but > that will require some work. > > Bill > In order to compile wine on x86_64 I had to install the X and openssl devel packages from the i386 repo. -- Brian Gerst From wtogami at redhat.com Wed Dec 7 20:14:00 2005 From: wtogami at redhat.com (Warren Togami) Date: Wed, 07 Dec 2005 15:14:00 -0500 Subject: i386 devel packages in x86_64 tree (alsa) In-Reply-To: <43974082.8040507@didntduck.org> References: <20051207193938.GB15719@devserv.devel.redhat.com> <43974082.8040507@didntduck.org> Message-ID: <43974288.4030508@redhat.com> Brian Gerst wrote: > Bill Nottingham wrote: > >> Orion Poplawski (orion at cora.nwra.com) said: >> >>> Is there a particular criteria for which i386 devel packages end up the >>> in the x86_64 tree? >> >> >> >> Generally, the LSB set. There is discussion of expanding it, but >> that will require some work. >> >> Bill >> > > In order to compile wine on x86_64 I had to install the X and openssl > devel packages from the i386 repo. > You folks might be happier rebuilding i386 SRPMS on your x86_64 by using mock. It is almost fully automated. Warren Togami wtogami at redhat.com From dimi at lattica.com Wed Dec 7 20:17:12 2005 From: dimi at lattica.com (Dimi Paun) Date: Wed, 7 Dec 2005 15:17:12 -0500 Subject: i386 devel packages in x86_64 tree (alsa) References: <20051207193938.GB15719@devserv.devel.redhat.com><43974082.8040507@didntduck.org> <43974288.4030508@redhat.com> Message-ID: <033f01c5fb6b$35ff6690$b6491b31@td612671> From: "Warren Togami" > > In order to compile wine on x86_64 I had to install the X and openssl > > devel packages from the i386 repo. > > > > You folks might be happier rebuilding i386 SRPMS on your x86_64 by using > mock. It is almost fully automated. IIRC, wine needs to be compiled as 32bit on x86_64. -- Dimi Paun Lattica, Inc. From warren at togami.com Wed Dec 7 20:25:57 2005 From: warren at togami.com (Warren Togami) Date: Wed, 07 Dec 2005 15:25:57 -0500 Subject: i386 devel packages in x86_64 tree (alsa) In-Reply-To: <033f01c5fb6b$35ff6690$b6491b31@td612671> References: <20051207193938.GB15719@devserv.devel.redhat.com><43974082.8040507@didntduck.org> <43974288.4030508@redhat.com> <033f01c5fb6b$35ff6690$b6491b31@td612671> Message-ID: <43974555.60700@togami.com> Dimi Paun wrote: > From: "Warren Togami" > >>>In order to compile wine on x86_64 I had to install the X and openssl >>>devel packages from the i386 repo. >>> >> >>You folks might be happier rebuilding i386 SRPMS on your x86_64 by using >>mock. It is almost fully automated. > > > IIRC, wine needs to be compiled as 32bit on x86_64. > Which is exactly what mock can do. Warren Togami wtogami at redhat.com From bgerst at didntduck.org Wed Dec 7 20:31:50 2005 From: bgerst at didntduck.org (Brian Gerst) Date: Wed, 07 Dec 2005 15:31:50 -0500 Subject: i386 devel packages in x86_64 tree (alsa) In-Reply-To: <43974288.4030508@redhat.com> References: <20051207193938.GB15719@devserv.devel.redhat.com> <43974082.8040507@didntduck.org> <43974288.4030508@redhat.com> Message-ID: <439746B6.3010500@didntduck.org> Warren Togami wrote: > Brian Gerst wrote: > >> Bill Nottingham wrote: >> >>> Orion Poplawski (orion at cora.nwra.com) said: >>> >>>> Is there a particular criteria for which i386 devel packages end up the >>>> in the x86_64 tree? >>> >>> >>> >>> >>> Generally, the LSB set. There is discussion of expanding it, but >>> that will require some work. >>> >>> Bill >>> >> >> In order to compile wine on x86_64 I had to install the X and openssl >> devel packages from the i386 repo. >> > > You folks might be happier rebuilding i386 SRPMS on your x86_64 by using > mock. It is almost fully automated. > > Warren Togami > wtogami at redhat.com > I'm not building it through RPM. Wine has the necessary logic to compile as 32-bit even on x86_64. All that is missing is the symbolic links from libfoo.so -> libfoo.so.x for the 32-bit libs, which the i386 devel packages provide. -- Brian Gerst From jakub at redhat.com Thu Dec 8 09:51:01 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Thu, 8 Dec 2005 04:51:01 -0500 Subject: Fedora development switch to GCC 4.1.0-RH prerelease Message-ID: <20051208095101.GA31785@devserv.devel.redhat.com> Hi! Some time between today and tomorrow we plan to switch Fedora development primary compiler from GCC 4.0.2-RH to 4.1.0-RH prerelease. We hope GCC 4.1.0 will be officially released in time for the Fedora Core 5 release, but if we want to switch, we need to do it now so that the compiler and packages built with it are sufficiently tested. For (so far preliminary) list of changes see http://gcc.gnu.org/gcc-4.1/changes.html (though, safe builtins and -fstack-protector has been already provided in GCC 4.0.2-RH). GCC 4.1.0-RH rpms are based on snapshots from svn://gcc.gnu.org/svn/gcc/branches/redhat/gcc-4_1-branch This branch is a merge between the upstream svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch and svn://gcc.gnu.org/svn/gcc/branches/gomp-20050608-branch which adds (preliminary) OpenMP 2.5 support. From our experience with building rawhide packages with this compiler, we know about a few outstanding GCC bugs that affect them: http://gcc.gnu.org/PR25240 (_Pragma parsing bug, prevents glibc build) http://gcc.gnu.org/PR25221 (reload ICE when compiling GIMP on i?86) http://gcc.gnu.org/PR25023 (ICE with pushw in struct by value passing and -g on i586 kernel) (of course there are many more regressions: http://gcc.gnu.org/bugzilla/buglist.cgi?query_format=advanced&short_desc_type=allwordssubstr&short_desc=4.1&target_milestone=4.0.3&target_milestone=4.1.0&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=SUSPENDED&bug_status=WAITING&bug_status=REOPENED&priority=P1&priority=P2&priority=P3 but those weren't seen in rawhide packages (so far)). The C++ frontend is again more strict then in GCC 4.0.x and rejects more invalid code. Problems seen in multiple packages include: "extra qualification..." errors - http://gcc.gnu.org/PR16782 friend injection change - struct A { typedef int S; friend void foo (S); friend void foo (); }; struct B { typedef int T; T t; void foo () { ::foo (t); } }; used to be accepted but is not any longer as ill-formed code. To fix this, the function needs to be declared at namespace scope, not just in a friend declaration. methods defined in wrong namespaces - struct A { void foo (); }; namespace { void A::foo () {} }; This is ill-formed, the definition needs to be done in the namespace containing the class. extern int bar (const char *); template struct A { void bar (const T &) { } }; template struct B : public A { B () : x (0) { } void baz () { bar (this->x); } const T x; }; void foo () { B b; b.baz (); } This is ill-formed, as bar is not template dependent and so it is looked up and found in the global namespace. The fix is to make the call template dependent, e.g. by using this->bar (this->x); relying on some C++ STL headers to include - some of the headers no longer include (on purpose), if you see this, just add explicit #include . Also packages that use -Werror might need some changes, because some new warnings were added (especially strict aliasing warnings in C++) and with -Werror that means the package doesn't build any longer. Please report any internal compiler errors as well as other problems where GCC is on fault (and that aren't in the above list) to http://bugzilla.redhat.com/bugzilla/ as usually, ideally the /tmp/cc*.out preprocessed source GCC driver creates for ICEs, or by manually preprocessing the source, verifying the bug is still reproduceable and also mentioning exact compiler version, architecture and all compiler options needed to reproduce it. If you want to test OpenMP, use -fopenmp option. Jakub -------------- 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 Thu Dec 8 11:18:24 2005 From: buildsys at redhat.com (Build System) Date: Thu, 8 Dec 2005 06:18:24 -0500 Subject: rawhide report: 20051208 changes Message-ID: <200512081118.jB8BIO9s015968@porkchop.devel.redhat.com> Updated Packages: GConf2-2.12.1-2 --------------- * Wed Dec 07 2005 Dan Williams 2.12.1-2 - Fix segfault in gconf_unescape_key(). GNOME #323479 anaconda-10.90.14-1 ------------------- * Thu Dec 08 2005 Jeremy Katz - 10.90.14-1 - Fix up for moved x locale data - Remove vnc hack now that VNC knows where to look for fonts - Don't go to text mode for no mouse (notting) - Update to work with yum 2.5.0 cvs snap - New package selection code - Add new chinese font back now that we're using squashfs (#172163) - The return of locale-archive usage * Mon Dec 05 2005 Chris Lumens 10.90.13-1 - Reword media check dialog (dcantrell, #174530). - gcc41 compile fixes (pjones). - Add genhomedircon, setfiles, and /etc/shells for selinux. * Thu Dec 01 2005 Jeremy Katz - 10.90.12-1 - some release notes viewer fixing (dcantrell) - allow %pre scripts in an %include (clumens, #166100) - fix the squashfs stuff to actually work - hack around slang not initializing utf8 mode so that we have line drawing chars (#174761) apr-1.2.2-3 ----------- * Wed Dec 07 2005 Joe Orton 1.2.2-3 - apr-1-config: strip more exports (#175124) avahi-0.6.1-1 ------------- * Mon Dec 12 2005 Jason Vas Dias - 0.6.1-1 - Upgrade to 0.6.1 bash-3.0-39 ----------- * Wed Dec 07 2005 Tim Waugh 3.0-39 - Missed a loop for improved sighandler patch (bug #169231). curl-7.15.1-1 ------------- * Thu Dec 08 2005 Ivana Varekova 7.15.1-1 - update to 7.15.1 (bug 175191) eclipse-1:3.1.1-1jpp_9fc ------------------------ * Wed Dec 07 2005 Andrew Overholt 3.1.1-1jpp_9fc - Add patch for launcher following symlinks (rh#168726, e.o#79592) - ifoox. - Remove launcher script. * Mon Dec 05 2005 Andrew Overholt 3.1.1-1jpp_8fc - Add eclipse-rcp-devel as a requirement of eclipse-platform-devel (rh#161267). - Updated splash screen (thanks to Diana Fong) (rh#170580). - Include and use rebuild-sdk-features (rh#173589). * Fri Dec 02 2005 Andrew Overholt 3.1.1-1jpp_8fc - Update EFJ patch (e.o#75333). - Update update-site-in-home-dir patch (e.o#90630) - bkonrath. elfutils-0.118-1 ---------------- * Sun Nov 27 2005 Roland McGrath - 0.118-1 - update to 0.118 - elflint: more tests. - libdwfl: New function dwfl_module_register_names. - libebl: New backend hook for register names. - Make sure -fexceptions is always in CFLAGS. * Tue Nov 22 2005 Roland McGrath - 0.117-2 - update to 0.117 - libdwfl: New function dwfl_module_return_value_location (#166118) - libebl: Backend improvements for several CPUs epic-4:2.2-2 ------------ * Tue Dec 06 2005 Jesse Keating 4:2.2-2 - Removed outdated patches - Added libexec dir for files * Tue Dec 06 2005 Jesse Keating 4:2.2-1 - rebuild evolution-2.5.2-1 ----------------- * Wed Dec 07 2005 David Malcolm - 2.5.2-1 - 2.5.2 - bump gtkhtml requirement from 3.7.6 to 3.9.2 - bump eds requirement from 1.4.1.1 to 1.5.2 - bump evo_major from 2.4 to 2.6 - updated patch 107 - updated patch 108 - updated patch 800, replacing rh-161817-attach-116019-conduit_pilot_link_updates.diff with evolution-2.5.2-fix-conduits.patch. Not yet complete. - disable pilot support for now (see #175160) - added hula plugin to list of packaged plugins - generalize gconf schema packaging to support changing evo_major * Fri Dec 02 2005 David Malcolm - 2.4.2-2 - force regeneration of the intltool files to prevent a problem where the tarball copy of intltool-merge.in was out of sync with the intltool.m4 in the latest shipped copy of intltool, which resulted in a broken intltool-merge script when the tree was reautotooled. (appears that the tarball was built with a CVS copy of intltool where @EXPANDED_LIBDIR@ had been renamed to @INTLTOOL_LIBDIR@, but our aclocal/intltool.m4 doesn't yet reflect that change) * Tue Nov 29 2005 David Malcolm - 2.4.2-1 - 2.4.2 - explicitly list the plugins that are packaged (#166234) - added build-time requirement on gstreamer-devel to cope with audio-inline plugin evolution-connector-2.5.2-1 --------------------------- * Wed Dec 07 2005 David Malcolm - 2.5.2-1 - 2.5.2 - bump evo_major from 2.4 to 2.6 - bump evolution requirement from 2.4.1 to 2.5.2 to ensure we get an appropriate underlying version of evolution - regenerate patch 200 findutils-1:4.2.27-1 -------------------- * Wed Dec 07 2005 Tim Waugh 1:4.2.27-1 - 4.2.27. - No longer need arg_max patch. hplip-0.9.7-3 ------------- * Wed Dec 07 2005 Tim Waugh 0.9.7-3 - Use upstream patch 0.9.7-2. - No longer need lpgetstatus or compile patches. httpd-2.2.0-3 ------------- * Wed Dec 07 2005 Joe Orton 2.2.0-3 - strip manual to just English content kernel-2.6.14-1.1743_FC5 ------------------------ * Wed Dec 07 2005 Dave Jones - Merge slab leak detector. * Tue Dec 06 2005 Dave Jones - Test build with gcc4.1 libdaemon-0.10-1 ---------------- * Mon Dec 12 2005 Jason Vas Dias - 0.10-1 - Update to 0.10 libselinux-1.28-1 ----------------- * Wed Dec 07 2005 Dan Walsh 1.28-1 - Update to never version * Wed Dec 07 2005 Dan Walsh 1.27.28-2 - Fix some of the python swig objects libsepol-1.10-1 --------------- * Wed Dec 07 2005 Dan Walsh 1.10-1 - Upgrade to latest from NSA libsetrans-0.1.11-1 ------------------- * Wed Dec 07 2005 Dan Walsh 0.1.11-1 - Move chcat to policycoreutils * Wed Dec 07 2005 Dan Walsh 0.1.10-1 - Fix handling of "" translation logwatch-7.1-4 -------------- * Thu Dec 08 2005 Ivana Varekova 7.1-4 - updated /etc/.../logwatch.conf file (bug 175233) neon-0.24.7-10 -------------- * Wed Dec 07 2005 Joe Orton 0.24.7-10 - strip unnecessary exports from .la file/neon-config policycoreutils-1.27.37-1 ------------------------- * Wed Dec 07 2005 Dan Walsh 1.27.37-1 - Update to match NSA - Add chcat to policycoreutils, adding +/- syntax ` pup-0.1.8-1 ----------- * Thu Dec 08 2005 Jeremy Katz - 0.1.8-1 - Work with either of yum 2.4.x or 2.5.x - Minor tweaks to packing and sizing redhat-menus-5.0.7-3 -------------------- * Wed Dec 07 2005 Matthias Clasen - 5.0.7-3 - hide the separator as well selinux-policy-2.1.0-1 ---------------------- * Wed Dec 07 2005 Dan Walsh 2.0.11-2. Add xdm policy setools-2.2-3 ------------- * Thu Nov 03 2005 Dan Walsh 2.2-3 - Move more gui files out of base into gui tetex-3.0-11 ------------ * Tue Dec 06 2005 Jindrich Novy 3.0-11 - apply patch from Derek Noonburg to fix CVE-2005-3193 xpdf overflows (#175110) vnc-4.1.1-29 ------------ * Thu Dec 08 2005 Tim Waugh 4.1.1-29 - Fix x0vncserver (bug #172410). yum-2.5.0-0.20051207 -------------------- * Wed Dec 07 2005 Jeremy Katz - 2.5.0-0.20051207 - update to cvs snap for new group code and lots of other stuff Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel = 0:2.6.14-1.1696_FC5 cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5smp cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel = 0:2.6.14-1.1696_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 systemtap - 0.5-2.i386 requires libdw.so.1(ELFUTILS_0.116) Broken deps for ia64 ---------------------------------------------------------- libsetrans - 0.1.11-1.ia64 requires libc.so.6(GLIBC_2.3.4) libsetrans - 0.1.11-1.ia64 requires libc.so.6(GLIBC_2.4) libsetrans - 0.1.11-1.ia64 requires libc.so.6(GLIBC_2.1) libsetrans - 0.1.11-1.ia64 requires libc.so.6(GLIBC_2.0) libsetrans - 0.1.11-1.ia64 requires libdl.so.2 libsetrans - 0.1.11-1.ia64 requires libc.so.6(GLIBC_2.1.3) libsetrans - 0.1.11-1.ia64 requires libc.so.6(GLIBC_2.3) libsetrans - 0.1.11-1.ia64 requires libc.so.6 libsetrans - 0.1.11-1.ia64 requires libselinux.so.1 rgmanager - 1.9.31-3.ia64 requires ccs systemtap - 0.5-2.ia64 requires libdw.so.1(ELFUTILS_0.116)(64bit) Broken deps for ppc ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 systemtap - 0.5-2.ppc requires libdw.so.1(ELFUTILS_0.116) Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 libsetrans - 0.1.11-1.ppc64 requires libc.so.6(GLIBC_2.3.4) libsetrans - 0.1.11-1.ppc64 requires libc.so.6(GLIBC_2.4) libsetrans - 0.1.11-1.ppc64 requires libc.so.6(GLIBC_2.1) libsetrans - 0.1.11-1.ppc64 requires libc.so.6(GLIBC_2.0) libsetrans - 0.1.11-1.ppc64 requires libdl.so.2 libsetrans - 0.1.11-1.ppc64 requires libc.so.6(GLIBC_2.1.3) libsetrans - 0.1.11-1.ppc64 requires libc.so.6(GLIBC_2.3) libsetrans - 0.1.11-1.ppc64 requires libc.so.6 libsetrans - 0.1.11-1.ppc64 requires libselinux.so.1 Broken deps for s390 ---------------------------------------------------------- rhythmbox - 0.9.1-1.s390 requires libdbus-1.so.1 rhythmbox - 0.9.1-1.s390 requires libdbus-glib-1.so.1 Broken deps for s390x ---------------------------------------------------------- rhythmbox - 0.9.1-1.s390x requires libdbus-1.so.1()(64bit) rhythmbox - 0.9.1-1.s390x requires libdbus-glib-1.so.1()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 systemtap - 0.5-2.x86_64 requires libdw.so.1(ELFUTILS_0.116)(64bit) From tmus at tmus.dk Thu Dec 8 12:35:40 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Thu, 08 Dec 2005 13:35:40 +0100 Subject: Fedora development switch to GCC 4.1.0-RH prerelease In-Reply-To: <20051208095101.GA31785@devserv.devel.redhat.com> References: <20051208095101.GA31785@devserv.devel.redhat.com> Message-ID: Jakub Jelinek wrote: > Hi! > > Some time between today and tomorrow we plan to switch Fedora development > primary compiler from GCC 4.0.2-RH to 4.1.0-RH prerelease. > We hope GCC 4.1.0 will be officially released in time for the > Fedora Core 5 release, but if we want to switch, we need to do it now > so that the compiler and packages built with it are sufficiently tested. > Cool, Do anyone have an idea if gcc4.1 is going to affect Fedora overall performance at all or in either good/bad ways? /Thomas From arjan at fenrus.demon.nl Thu Dec 8 12:42:50 2005 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Thu, 08 Dec 2005 13:42:50 +0100 Subject: Fedora development switch to GCC 4.1.0-RH prerelease In-Reply-To: References: <20051208095101.GA31785@devserv.devel.redhat.com> Message-ID: <1134045770.2867.53.camel@laptopd505.fenrus.org> On Thu, 2005-12-08 at 13:35 +0100, Thomas M Steenholdt wrote: > Jakub Jelinek wrote: > > Hi! > > > > Some time between today and tomorrow we plan to switch Fedora development > > primary compiler from GCC 4.0.2-RH to 4.1.0-RH prerelease. > > We hope GCC 4.1.0 will be officially released in time for the > > Fedora Core 5 release, but if we want to switch, we need to do it now > > so that the compiler and packages built with it are sufficiently tested. > > > Cool, > > Do anyone have an idea if gcc4.1 is going to affect Fedora overall > performance at all or in either good/bad ways? one thing that will be good is that this version of gcc automatically detects that variables are never written to, and puts then in a special ELF section; the result is that shared libs and binaries share that memory between them instead of one for each app, and the total memory usage of fedora will go down a bit as a result! From fedora at camperquake.de Thu Dec 8 12:54:42 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 8 Dec 2005 13:54:42 +0100 Subject: Fedora development switch to GCC 4.1.0-RH prerelease In-Reply-To: <1134045770.2867.53.camel@laptopd505.fenrus.org> References: <20051208095101.GA31785@devserv.devel.redhat.com> <1134045770.2867.53.camel@laptopd505.fenrus.org> Message-ID: <20051208125441.GA17256@ryoko.camperquake.de> On Thu, Dec 08, 2005 at 01:42:50PM +0100, Arjan van de Ven wrote: > one thing that will be good is that this version of gcc automatically > detects that variables are never written to, and puts then in a special > ELF section; the result is that shared libs and binaries share that > memory between them instead of one for each app, and the total memory > usage of fedora will go down a bit as a result! Errr.. sorry, but what are shared variables that no one ever writes to exactly good for? From arjan at fenrus.demon.nl Thu Dec 8 13:09:22 2005 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Thu, 08 Dec 2005 14:09:22 +0100 Subject: Fedora development switch to GCC 4.1.0-RH prerelease In-Reply-To: <20051208125441.GA17256@ryoko.camperquake.de> References: <20051208095101.GA31785@devserv.devel.redhat.com> <1134045770.2867.53.camel@laptopd505.fenrus.org> <20051208125441.GA17256@ryoko.camperquake.de> Message-ID: <1134047363.2867.55.camel@laptopd505.fenrus.org> On Thu, 2005-12-08 at 13:54 +0100, Ralf Ertzinger wrote: > On Thu, Dec 08, 2005 at 01:42:50PM +0100, Arjan van de Ven wrote: > > > one thing that will be good is that this version of gcc automatically > > detects that variables are never written to, and puts then in a special > > ELF section; the result is that shared libs and binaries share that > > memory between them instead of one for each app, and the total memory > > usage of fedora will go down a bit as a result! > > Errr.. sorry, but what are shared variables that no one ever writes > to exactly good for? it's mostly tables, for example an ascii to unicode conversion table. But there's dozens and dozens of tables in all kinds of shapes and forms. From jbarnes at virtuousgeek.org Thu Dec 8 18:05:13 2005 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Thu, 8 Dec 2005 10:05:13 -0800 Subject: Fedora development switch to GCC 4.1.0-RH prerelease In-Reply-To: <20051208095101.GA31785@devserv.devel.redhat.com> References: <20051208095101.GA31785@devserv.devel.redhat.com> Message-ID: <200512081005.13753.jbarnes@virtuousgeek.org> On Thursday, December 8, 2005 1:51 am, Jakub Jelinek wrote: > Hi! > > Some time between today and tomorrow we plan to switch Fedora > development primary compiler from GCC 4.0.2-RH to 4.1.0-RH prerelease. > We hope GCC 4.1.0 will be officially released in time for the > Fedora Core 5 release, but if we want to switch, we need to do it now > so that the compiler and packages built with it are sufficiently > tested. Arjan mentioned the other day that the Fedora linker is capable of loading CPU specific libraries, depending on which ISA extensions are available. Since gcc 4.1 has a much improved autovectorizer, maybe now is the time to start making use of it? It seems like codec libraries are good candidates for autovectorization, maybe their spec files could build SSE2, SSE3, and 3dnow variants along with the regular, non-SIMD versions of the libraries? Of course, if the vectorizer doesn't actually vectorize anything in a given library, trying to use it is a waste of time, but fortunately gcc makes it fairly easy to see how effective the vectorizing pass was using -ftree-vectorizer-verbose (sp?). Anyway, just a thought. I'm pretty sure my VIA CPU would benefit from 3dnow versions of libraries, and it seems a shame to let the SSE3 extensions sit idle when gcc can take advantage of them fairly easily these days... Jesse From jbarnes at virtuousgeek.org Thu Dec 8 18:09:36 2005 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Thu, 8 Dec 2005 10:09:36 -0800 Subject: Fedora development switch to GCC 4.1.0-RH prerelease In-Reply-To: <200512081005.13753.jbarnes@virtuousgeek.org> References: <20051208095101.GA31785@devserv.devel.redhat.com> <200512081005.13753.jbarnes@virtuousgeek.org> Message-ID: <200512081009.37035.jbarnes@virtuousgeek.org> On Thursday, December 8, 2005 10:05 am, Jesse Barnes wrote: > Anyway, just a thought. I'm pretty sure my VIA CPU would benefit from > 3dnow versions of libraries, and it seems a shame to let the SSE3 > extensions sit idle when gcc can take advantage of them fairly easily > these days... FYI, on my system, the only package that seems to make use of /usr/lib/(3dnow|sse2|sse3) seems to be gmp, the GNU MP math library. Jesse From arjan at fenrus.demon.nl Thu Dec 8 18:15:48 2005 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Thu, 08 Dec 2005 19:15:48 +0100 Subject: Fedora development switch to GCC 4.1.0-RH prerelease In-Reply-To: <200512081005.13753.jbarnes@virtuousgeek.org> References: <20051208095101.GA31785@devserv.devel.redhat.com> <200512081005.13753.jbarnes@virtuousgeek.org> Message-ID: <1134065749.2867.93.camel@laptopd505.fenrus.org> On Thu, 2005-12-08 at 10:05 -0800, Jesse Barnes wrote: > On Thursday, December 8, 2005 1:51 am, Jakub Jelinek wrote: > > Hi! > > > > Some time between today and tomorrow we plan to switch Fedora > > development primary compiler from GCC 4.0.2-RH to 4.1.0-RH prerelease. > > We hope GCC 4.1.0 will be officially released in time for the > > Fedora Core 5 release, but if we want to switch, we need to do it now > > so that the compiler and packages built with it are sufficiently > > tested. > > Arjan mentioned the other day that the Fedora linker is capable of > loading CPU specific libraries, depending on which ISA extensions are > available. Since gcc 4.1 has a much improved autovectorizer, maybe now > is the time to start making use of it? It seems like codec libraries > are good candidates for autovectorization, maybe their spec files could > build SSE2, SSE3, and 3dnow variants along with the regular, non-SIMD > versions of the libraries? on x86-64 that's already there. on x86.. why ? From kloczek at zie.pg.gda.pl Thu Dec 8 18:35:19 2005 From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=) Date: Thu, 08 Dec 2005 19:35:19 +0100 Subject: rawhide report: 20051207 changes In-Reply-To: <200512071111.jB7BBiXL026956@porkchop.devel.redhat.com> References: <200512071111.jB7BBiXL026956@porkchop.devel.redhat.com> Message-ID: <1134066919.2631.11.camel@test1.zie.pg.gda.pl> Dnia 07-12-2005, ?ro o godzinie 06:11 -0500, Build System napisa?(a): [..] > Broken deps for x86_86 [..] It will be good add two new tests for detect: 1) file conflicts between packages in repository. From today update on x86_64: Transaction Check Error: file /usr/bin/chcat from install of policycoreutils-1.27.37-1 conflicts with file from package libsetrans-0.1.9-1 file /usr/share/man/man8/chcat.8.gz from install of policycoreutils-1.27.37-1 conflicts with file from package libsetrans-0.1.9-1 2) list of packages which owns the same directory for generate informations which allow fix bus like: $ rpm -qf /usr/bin | wc -l; rpm -qf /usr/share/pixmaps | wc -l 16 17 $ rpm -qf /usr/bin filesystem-2.3.7-1 xorg-x11-xkb-utils-0.99.1-2 xorg-x11-utils-0.99.2-3 xorg-x11-twm-0.99.1-3 xorg-x11-xfs-0.99.2-4 xorg-x11-resutils-0.99.1-3 xorg-x11-xauth-0.99.2-1 xorg-x11-xfwp-0.99.1-3 xorg-x11-xinit-0.99.3-6 xorg-x11-font-utils-0.99.1-1 xorg-x11-xsm-0.99.2-4 xorg-x11-apps-0.99.2-4 xorg-x11-server-Xorg-0.99.3-9 xorg-x11-server-Xnest-0.99.3-9 xorg-x11-xdm-0.99.3-6 xorg-x11-server-utils-0.99.2-6 BTW. Why still isn't closed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174484 In report is included fixed spec file and patch. Without this Xnest is unuseable. kloczek From jbarnes at virtuousgeek.org Thu Dec 8 18:36:18 2005 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Thu, 8 Dec 2005 10:36:18 -0800 Subject: Fedora development switch to GCC 4.1.0-RH prerelease In-Reply-To: <1134065749.2867.93.camel@laptopd505.fenrus.org> References: <20051208095101.GA31785@devserv.devel.redhat.com> <200512081005.13753.jbarnes@virtuousgeek.org> <1134065749.2867.93.camel@laptopd505.fenrus.org> Message-ID: <200512081036.18905.jbarnes@virtuousgeek.org> On Thursday, December 8, 2005 10:15 am, Arjan van de Ven wrote: > > Arjan mentioned the other day that the Fedora linker is capable of > > loading CPU specific libraries, depending on which ISA extensions > > are available. Since gcc 4.1 has a much improved autovectorizer, > > maybe now is the time to start making use of it? It seems like > > codec libraries are good candidates for autovectorization, maybe > > their spec files could build SSE2, SSE3, and 3dnow variants along > > with the regular, non-SIMD versions of the libraries? > > on x86-64 that's already there. on x86.. why ? There are still lots of x86 machines out there, including the upcoming, dual-core Yonah chip, so providing SIMD versions of the libraries for x86 is worthwhile, IMO. Which libraries have vectorized variants on x86-64? I only saw one for my x86 box... jesse From arjan at fenrus.demon.nl Thu Dec 8 18:47:21 2005 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Thu, 08 Dec 2005 19:47:21 +0100 Subject: Fedora development switch to GCC 4.1.0-RH prerelease In-Reply-To: <200512081036.18905.jbarnes@virtuousgeek.org> References: <20051208095101.GA31785@devserv.devel.redhat.com> <200512081005.13753.jbarnes@virtuousgeek.org> <1134065749.2867.93.camel@laptopd505.fenrus.org> <200512081036.18905.jbarnes@virtuousgeek.org> Message-ID: <1134067642.2867.95.camel@laptopd505.fenrus.org> On Thu, 2005-12-08 at 10:36 -0800, Jesse Barnes wrote: > On Thursday, December 8, 2005 10:15 am, Arjan van de Ven wrote: > > > Arjan mentioned the other day that the Fedora linker is capable of > > > loading CPU specific libraries, depending on which ISA extensions > > > are available. Since gcc 4.1 has a much improved autovectorizer, > > > maybe now is the time to start making use of it? It seems like > > > codec libraries are good candidates for autovectorization, maybe > > > their spec files could build SSE2, SSE3, and 3dnow variants along > > > with the regular, non-SIMD versions of the libraries? > > > > on x86-64 that's already there. on x86.. why ? > > There are still lots of x86 machines out there, including the upcoming, > dual-core Yonah chip, so providing SIMD versions of the libraries for > x86 is worthwhile, IMO. > > Which libraries have vectorized variants on x86-64? I only saw one for > my x86 box... on x86-64 all do.. SSE2 etc are "core" features there and don't need special dirs, it's part of the normal ABI From jbarnes at virtuousgeek.org Thu Dec 8 18:55:57 2005 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Thu, 8 Dec 2005 10:55:57 -0800 Subject: Fedora development switch to GCC 4.1.0-RH prerelease In-Reply-To: <1134067642.2867.95.camel@laptopd505.fenrus.org> References: <20051208095101.GA31785@devserv.devel.redhat.com> <200512081036.18905.jbarnes@virtuousgeek.org> <1134067642.2867.95.camel@laptopd505.fenrus.org> Message-ID: <200512081055.57852.jbarnes@virtuousgeek.org> On Thursday, December 8, 2005 10:47 am, Arjan van de Ven wrote: > > Which libraries have vectorized variants on x86-64? I only saw one > > for my x86 box... > > on x86-64 all do.. SSE2 etc are "core" features there and don't need > special dirs, it's part of the normal ABI That's just SSE2 style FP though, right? The autovectorizer isn't enabled is it? Jesse From arjan at fenrus.demon.nl Thu Dec 8 19:00:36 2005 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Thu, 08 Dec 2005 20:00:36 +0100 Subject: Fedora development switch to GCC 4.1.0-RH prerelease In-Reply-To: <200512081055.57852.jbarnes@virtuousgeek.org> References: <20051208095101.GA31785@devserv.devel.redhat.com> <200512081036.18905.jbarnes@virtuousgeek.org> <1134067642.2867.95.camel@laptopd505.fenrus.org> <200512081055.57852.jbarnes@virtuousgeek.org> Message-ID: <1134068436.2867.97.camel@laptopd505.fenrus.org> On Thu, 2005-12-08 at 10:55 -0800, Jesse Barnes wrote: > On Thursday, December 8, 2005 10:47 am, Arjan van de Ven wrote: > > > Which libraries have vectorized variants on x86-64? I only saw one > > > for my x86 box... > > > > on x86-64 all do.. SSE2 etc are "core" features there and don't need > > special dirs, it's part of the normal ABI > > That's just SSE2 style FP though, right? The autovectorizer isn't > enabled is it? > I thought it was.. jakub will know From alan at redhat.com Thu Dec 8 19:00:52 2005 From: alan at redhat.com (Alan Cox) Date: Thu, 8 Dec 2005 14:00:52 -0500 Subject: Fedora development switch to GCC 4.1.0-RH prerelease In-Reply-To: <200512081009.37035.jbarnes@virtuousgeek.org> References: <20051208095101.GA31785@devserv.devel.redhat.com> <200512081005.13753.jbarnes@virtuousgeek.org> <200512081009.37035.jbarnes@virtuousgeek.org> Message-ID: <20051208190052.GB26968@devserv.devel.redhat.com> On Thu, Dec 08, 2005 at 10:09:36AM -0800, Jesse Barnes wrote: > FYI, on my system, the only package that seems to make use > of /usr/lib/(3dnow|sse2|sse3) seems to be gmp, the GNU MP math library. Some other libraries handle it internally because they need to be cross platform - mesa is a good example here. From dnovillo at redhat.com Thu Dec 8 19:01:20 2005 From: dnovillo at redhat.com (Diego Novillo) Date: Thu, 8 Dec 2005 14:01:20 -0500 Subject: Fedora development switch to GCC 4.1.0-RH prerelease In-Reply-To: <200512081055.57852.jbarnes@virtuousgeek.org> References: <20051208095101.GA31785@devserv.devel.redhat.com> <1134067642.2867.95.camel@laptopd505.fenrus.org> <200512081055.57852.jbarnes@virtuousgeek.org> Message-ID: <200512081401.21054.dnovillo@redhat.com> On Thursday 08 December 2005 13:55, Jesse Barnes wrote: > That's just SSE2 style FP though, right? The autovectorizer isn't > enabled is it? > Not by default, no. You need to enable it explicitly with -ftree-vectorize. From jbarnes at virtuousgeek.org Thu Dec 8 19:14:09 2005 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Thu, 8 Dec 2005 11:14:09 -0800 Subject: Fedora development switch to GCC 4.1.0-RH prerelease In-Reply-To: <20051208190052.GB26968@devserv.devel.redhat.com> References: <20051208095101.GA31785@devserv.devel.redhat.com> <200512081009.37035.jbarnes@virtuousgeek.org> <20051208190052.GB26968@devserv.devel.redhat.com> Message-ID: <200512081114.09426.jbarnes@virtuousgeek.org> On Thursday, December 8, 2005 11:00 am, Alan Cox wrote: > On Thu, Dec 08, 2005 at 10:09:36AM -0800, Jesse Barnes wrote: > > FYI, on my system, the only package that seems to make use > > of /usr/lib/(3dnow|sse2|sse3) seems to be gmp, the GNU MP math > > library. > > Some other libraries handle it internally because they need to be > cross platform - mesa is a good example here. Right, those libraries are already good to go; I'm thinking of things like libjpeg or libtheora (in fact, I tried the new vectorizer on libjpeg and it was able to vectorize quite a few loops, so I'm hopeful that other libraries will be similarly optimized). I don't think they include SSE or 3dnow specific loops with runtime detection. And rather than going through the process of hand tuning them with assembly, it seems worthwhile to tweak their critical loops such that they can be autovectorized by gcc, that way any platform with a gcc autovectorization target can benefit. Jesse From dravet at hotmail.com Thu Dec 8 19:54:25 2005 From: dravet at hotmail.com (Jason Dravet) Date: Thu, 08 Dec 2005 13:54:25 -0600 Subject: gstreamer 0.10 Message-ID: Is gstreamer 0.10 going to be in FC5T2? Thanks, Jason From jbarnes at virtuousgeek.org Thu Dec 8 20:08:57 2005 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Thu, 8 Dec 2005 12:08:57 -0800 Subject: kpdf disappeared? Message-ID: <200512081208.57646.jbarnes@virtuousgeek.org> kpdf seems to have disappeared since my upgrade. I googled around to see if it was removed for some reason, but didn't come up with anything. The kdegraphics source package seems to include it, but the binary package doesn't, and the changelog doesn't mention any reason why it would be omitted. What's up? Thanks, Jesse From gilboada at netvision.net.il Thu Dec 8 20:19:30 2005 From: gilboada at netvision.net.il (Gilboa Davara) Date: Thu, 08 Dec 2005 22:19:30 +0200 Subject: gstreamer 0.10 In-Reply-To: References: Message-ID: <1134073170.12155.0.camel@gilboa-home-dev.localhost> On Thu, 2005-12-08 at 13:54 -0600, Jason Dravet wrote: > Is gstreamer 0.10 going to be in FC5T2? > > Thanks, > Jason > > I sure hope so. 0.8 has severe problems when using arts that are supposed to be fixed in 0.10. Gilboa From ndbecker2 at gmail.com Thu Dec 8 20:32:34 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 08 Dec 2005 15:32:34 -0500 Subject: yum clean bug Message-ID: I noticed that with yum-2.4.1-1.fc4 that yum clean all doesn't clean disabled repos. You have to say --enablerepo=. I think clean all should clean all. From skvidal at phy.duke.edu Thu Dec 8 20:42:45 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 08 Dec 2005 15:42:45 -0500 Subject: yum clean bug In-Reply-To: References: Message-ID: <1134074565.23944.39.camel@cutter> On Thu, 2005-12-08 at 15:32 -0500, Neal Becker wrote: > I noticed that with yum-2.4.1-1.fc4 that yum clean all doesn't clean > disabled repos. You have to say --enablerepo=. I think clean all should > clean all. think about what you're saying: "Yum should act on a repository even though you have told it not to" Does that sound terribly intuitive to you? -sv From ivazquez at ivazquez.net Thu Dec 8 20:41:52 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 08 Dec 2005 15:41:52 -0500 Subject: yum clean bug In-Reply-To: References: Message-ID: <1134074513.32688.5.camel@ignacio.lan> On Thu, 2005-12-08 at 15:32 -0500, Neal Becker wrote: > I noticed that with yum-2.4.1-1.fc4 that yum clean all doesn't clean > disabled repos. You have to say --enablerepo=. I think clean all should > clean all. But then you lose the ability to selectively clean repos. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Thu Dec 8 20:44:00 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 8 Dec 2005 15:44:00 -0500 Subject: yum clean bug In-Reply-To: References: Message-ID: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> On 12/8/05, Neal Becker wrote: > I noticed that with yum-2.4.1-1.fc4 that yum clean all doesn't clean > disabled repos. You have to say --enablerepo=. I think clean all should > clean all. yum --enablerepo=* clean all -jef From strange at nsk.no-ip.org Thu Dec 8 20:51:37 2005 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Thu, 8 Dec 2005 20:51:37 +0000 Subject: yum clean bug In-Reply-To: <1134074565.23944.39.camel@cutter> References: <1134074565.23944.39.camel@cutter> Message-ID: <20051208205137.GA10102@nsk.no-ip.org> On Thu, Dec 08, 2005 at 03:42:45PM -0500, seth vidal wrote: > On Thu, 2005-12-08 at 15:32 -0500, Neal Becker wrote: > > I noticed that with yum-2.4.1-1.fc4 that yum clean all doesn't clean > > disabled repos. You have to say --enablerepo=. I think clean all should > > clean all. > > > think about what you're saying: "Yum should act on a repository even > though you have told it not to" > > Does that sound terribly intuitive to you? Yes. Because I'm doing cache operations, not repository operations. Or rather, that's what I thought I was doing, so it would be intuitive to me. -- lfr 0/0 From jspaleta at gmail.com Thu Dec 8 20:55:46 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 8 Dec 2005 15:55:46 -0500 Subject: yum clean bug In-Reply-To: <20051208205137.GA10102@nsk.no-ip.org> References: <1134074565.23944.39.camel@cutter> <20051208205137.GA10102@nsk.no-ip.org> Message-ID: <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> On 12/8/05, Luciano Miguel Ferreira Rocha wrote: > Yes. Because I'm doing cache operations, not repository operations. Or > rather, that's what I thought I was doing, so it would be intuitive to > me. So for completeness what your saying is that you think yum clean packages should clean all packages from all enabled and disabled repos by default? and yum clean headers should clean all headers from all enabled and disabled repos by default? -jef From michael.favia at insitesinc.com Thu Dec 8 21:06:48 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Thu, 08 Dec 2005 15:06:48 -0600 Subject: yum clean bug In-Reply-To: <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> References: <1134074565.23944.39.camel@cutter> <20051208205137.GA10102@nsk.no-ip.org> <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> Message-ID: <4398A068.4060602@insitesinc.com> Jeff Spaleta wrote: > On 12/8/05, Luciano Miguel Ferreira Rocha wrote: >> Yes. Because I'm doing cache operations, not repository operations. Or >> rather, that's what I thought I was doing, so it would be intuitive to >> me. > > So for completeness what your saying is that you think > yum clean packages should clean all packages from all enabled and > disabled repos by default? > > and yum clean headers should clean all headers from all enabled and > disabled repos by default? I think that if it were that way by default we would be having the discussion of adding the ability to enablerepo and disablerepo for the command instead :). I think it makes more sense to enable all repos for just such an operation. Is this possible currently via shortcut ? -mf From cra at WPI.EDU Thu Dec 8 21:18:24 2005 From: cra at WPI.EDU (Chuck Anderson) Date: Thu, 8 Dec 2005 16:18:24 -0500 Subject: yum clean bug In-Reply-To: <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> References: <1134074565.23944.39.camel@cutter> <20051208205137.GA10102@nsk.no-ip.org> <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> Message-ID: <20051208211824.GQ2168@angus.ind.WPI.EDU> On Thu, Dec 08, 2005 at 03:55:46PM -0500, Jeff Spaleta wrote: > So for completeness what your saying is that you think > yum clean packages should clean all packages from all enabled and > disabled repos by default? A related problem is cleaning the cache of repos that are no longer configured. E.g. the move from pre-extras to extras left a cache from pre-extras lying around. From strange at nsk.no-ip.org Thu Dec 8 21:21:33 2005 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Thu, 8 Dec 2005 21:21:33 +0000 Subject: yum clean bug In-Reply-To: <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> References: <1134074565.23944.39.camel@cutter> <20051208205137.GA10102@nsk.no-ip.org> <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> Message-ID: <20051208212133.GB10102@nsk.no-ip.org> On Thu, Dec 08, 2005 at 03:55:46PM -0500, Jeff Spaleta wrote: > On 12/8/05, Luciano Miguel Ferreira Rocha wrote: > > Yes. Because I'm doing cache operations, not repository operations. Or > > rather, that's what I thought I was doing, so it would be intuitive to > > me. > > So for completeness what your saying is that you think > yum clean packages should clean all packages from all enabled and > disabled repos by default? > > and yum clean headers should clean all headers from all enabled and > disabled repos by default? Yes. I often do that prior to backing up and/or imaging a system. That's just my opinion, of course, and I can live with the current behaviour (I always check /var for "deletable" data before backing up/etc., anyway). (Actually, I didn't even expect yum to check repository configuration. Just to remove */headers, */packages, ...) -- lfr 0/0 From pmatilai at laiskiainen.org Thu Dec 8 21:51:36 2005 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 08 Dec 2005 23:51:36 +0200 Subject: yum clean bug In-Reply-To: <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> References: <1134074565.23944.39.camel@cutter> <20051208205137.GA10102@nsk.no-ip.org> <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> Message-ID: <1134078696.1536.1.camel@weasel.turre.laiskiainen.org> On Thu, 2005-12-08 at 15:55 -0500, Jeff Spaleta wrote: > On 12/8/05, Luciano Miguel Ferreira Rocha wrote: > > Yes. Because I'm doing cache operations, not repository operations. Or > > rather, that's what I thought I was doing, so it would be intuitive to > > me. > > So for completeness what your saying is that you think > yum clean packages should clean all packages from all enabled and > disabled repos by default? > > and yum clean headers should clean all headers from all enabled and > disabled repos by default? Well, I actually think it should. - Panu - From skvidal at phy.duke.edu Thu Dec 8 21:59:34 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 08 Dec 2005 16:59:34 -0500 Subject: yum clean bug In-Reply-To: <1134078696.1536.1.camel@weasel.turre.laiskiainen.org> References: <1134074565.23944.39.camel@cutter> <20051208205137.GA10102@nsk.no-ip.org> <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> <1134078696.1536.1.camel@weasel.turre.laiskiainen.org> Message-ID: <1134079174.23944.48.camel@cutter> On Thu, 2005-12-08 at 23:51 +0200, Panu Matilainen wrote: > On Thu, 2005-12-08 at 15:55 -0500, Jeff Spaleta wrote: > > On 12/8/05, Luciano Miguel Ferreira Rocha wrote: > > > Yes. Because I'm doing cache operations, not repository operations. Or > > > rather, that's what I thought I was doing, so it would be intuitive to > > > me. > > > > So for completeness what your saying is that you think > > yum clean packages should clean all packages from all enabled and > > disabled repos by default? > > > > and yum clean headers should clean all headers from all enabled and > > disabled repos by default? > > Well, I actually think it should. Seriously? That seems completely backward to me. it's like saying rsync --exclude=/some/path should not actually exclude that path. or that a disabled samba share shouldn't ACTUALLY be disabled. why on earth do you think yum should do what it's been told NOT to do? -sv From strange at nsk.no-ip.org Thu Dec 8 22:15:41 2005 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Thu, 8 Dec 2005 22:15:41 +0000 Subject: yum clean bug In-Reply-To: <1134079174.23944.48.camel@cutter> References: <1134074565.23944.39.camel@cutter> <20051208205137.GA10102@nsk.no-ip.org> <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> <1134078696.1536.1.camel@weasel.turre.laiskiainen.org> <1134079174.23944.48.camel@cutter> Message-ID: <20051208221541.GC10102@nsk.no-ip.org> On Thu, Dec 08, 2005 at 04:59:34PM -0500, seth vidal wrote: > On Thu, 2005-12-08 at 23:51 +0200, Panu Matilainen wrote: > > On Thu, 2005-12-08 at 15:55 -0500, Jeff Spaleta wrote: > > > On 12/8/05, Luciano Miguel Ferreira Rocha wrote: > > > > Yes. Because I'm doing cache operations, not repository operations. Or > > > > rather, that's what I thought I was doing, so it would be intuitive to > > > > me. > > > > > > So for completeness what your saying is that you think > > > yum clean packages should clean all packages from all enabled and > > > disabled repos by default? > > > > > > and yum clean headers should clean all headers from all enabled and > > > disabled repos by default? > > > > Well, I actually think it should. > > > Seriously? That seems completely backward to me. > > it's like saying rsync --exclude=/some/path should not actually exclude > that path. > > or that a disabled samba share shouldn't ACTUALLY be disabled. Bad analogies. We're talking about cache data. I don't even understand why is it necessary to gather repositories configuration. Don't forget that current behaviour makes it unable to delete cache for repositories no longer configurated. Unless by hand. -- lfr 0/0 From tmus at tmus.dk Thu Dec 8 22:14:39 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Thu, 08 Dec 2005 23:14:39 +0100 Subject: yum clean bug In-Reply-To: <4398A068.4060602@insitesinc.com> References: <1134074565.23944.39.camel@cutter> <20051208205137.GA10102@nsk.no-ip.org> <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> <4398A068.4060602@insitesinc.com> Message-ID: Michael Favia wrote: > Jeff Spaleta wrote: >> On 12/8/05, Luciano Miguel Ferreira Rocha wrote: >>> Yes. Because I'm doing cache operations, not repository operations. Or >>> rather, that's what I thought I was doing, so it would be intuitive to >>> me. >> >> So for completeness what your saying is that you think >> yum clean packages should clean all packages from all enabled and >> disabled repos by default? >> >> and yum clean headers should clean all headers from all enabled and >> disabled repos by default? > > I think that if it were that way by default we would be having the > discussion of adding the ability to enablerepo and disablerepo for the > command instead :). I think it makes more sense to enable all repos for > just such an operation. Is this possible currently via shortcut ? -mf > Actually, IMO, yum clean packages should not care about repos at all. It should remove packages for anything in yum cache - including enable, disabled and no-longer-existing repos. From a look at the yum man page it seems that this was also the idea that the developers hade when they made those commands... --- snip --- *yum clean packages* Eliminate any cached packages from the system. Note that pack- ages are not automatically deleted after they are downloaded. *yum clean headers* Eliminate all of the files which yum uses to determine the remote availability of packages. Using this option will force yum to download all the headers the next time it is run. *yum clean all* Runs yum clean packages and yum clean headers as above. --- snip --- no reference to repos are made here. Also, if only cleaning for enabled repos, we can't use yum to clean out it's stuff for no-longer-existing repos, which would be bad. /Thomas From skvidal at phy.duke.edu Thu Dec 8 22:23:00 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 08 Dec 2005 17:23:00 -0500 Subject: yum clean bug In-Reply-To: <20051208221541.GC10102@nsk.no-ip.org> References: <1134074565.23944.39.camel@cutter> <20051208205137.GA10102@nsk.no-ip.org> <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> <1134078696.1536.1.camel@weasel.turre.laiskiainen.org> <1134079174.23944.48.camel@cutter> <20051208221541.GC10102@nsk.no-ip.org> Message-ID: <1134080580.23944.54.camel@cutter> On Thu, 2005-12-08 at 22:15 +0000, Luciano Miguel Ferreira Rocha wrote: > Bad analogies. We're talking about cache data. > > I don't even understand why is it necessary to gather repositories > configuration. > > Don't forget that current behaviour makes it unable to delete cache for > repositories no longer configurated. Unless by hand. > CLOSED->WONTFIX It's not going to happen. end of story. -sv From tmus at tmus.dk Thu Dec 8 22:22:01 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Thu, 08 Dec 2005 23:22:01 +0100 Subject: yum clean bug In-Reply-To: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > On 12/8/05, Neal Becker wrote: >> I noticed that with yum-2.4.1-1.fc4 that yum clean all doesn't clean >> disabled repos. You have to say --enablerepo=. I think clean all should >> clean all. > > yum --enablerepo=* clean all > > -jef > How about repos that have been renamed or removed? Should we just accept that the cache for those repos will continue to waste space on our harddrives for eternity? /Thomas From skvidal at phy.duke.edu Thu Dec 8 22:30:36 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 08 Dec 2005 17:30:36 -0500 Subject: yum clean bug In-Reply-To: References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> Message-ID: <1134081037.23944.58.camel@cutter> On Thu, 2005-12-08 at 23:22 +0100, Thomas M Steenholdt wrote: > Jeff Spaleta wrote: > > On 12/8/05, Neal Becker wrote: > >> I noticed that with yum-2.4.1-1.fc4 that yum clean all doesn't clean > >> disabled repos. You have to say --enablerepo=. I think clean all should > >> clean all. > > > > yum --enablerepo=* clean all > > > > -jef > > > > How about repos that have been renamed or removed? Should we just accept > that the cache for those repos will continue to waste space on our > harddrives for eternity? > you should accept that yum no longer has any information on those repos or where their cache information is stored. -sv From tmus at tmus.dk Thu Dec 8 22:19:54 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Thu, 08 Dec 2005 23:19:54 +0100 Subject: yum clean bug In-Reply-To: <1134079174.23944.48.camel@cutter> References: <1134074565.23944.39.camel@cutter> <20051208205137.GA10102@nsk.no-ip.org> <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> <1134078696.1536.1.camel@weasel.turre.laiskiainen.org> <1134079174.23944.48.camel@cutter> Message-ID: seth vidal wrote: > > why on earth do you think yum should do what it's been told NOT to do? > > -sv the clean functions, to me, represents a way to make yum clean out it's stored data - it really has nothing to do with whether or not a repo is enabled, because the clean commands has nothing to do with repo intervention as such. just cleans out the cache. A slightly different take is this - why do we want to waste space on cache for a repo that is disabled? /Thomas From skvidal at phy.duke.edu Thu Dec 8 22:42:06 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 08 Dec 2005 17:42:06 -0500 Subject: yum clean bug In-Reply-To: References: <1134074565.23944.39.camel@cutter> <20051208205137.GA10102@nsk.no-ip.org> <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> <1134078696.1536.1.camel@weasel.turre.laiskiainen.org> <1134079174.23944.48.camel@cutter> Message-ID: <1134081726.23944.61.camel@cutter> On Thu, 2005-12-08 at 23:19 +0100, Thomas M Steenholdt wrote: > seth vidal wrote: > > > > why on earth do you think yum should do what it's been told NOT to do? > > > > -sv > > the clean functions, to me, represents a way to make yum clean out it's > stored data - it really has nothing to do with whether or not a repo is > enabled, because the clean commands has nothing to do with repo > intervention as such. just cleans out the cache. But how can I really be sure that ALL the data in that dir is disposable, especially if the user has disabled the repo in question in their config. I err on the side of protecting data. If yum is not told to remove it, then it won't remove it. > A slightly different take is this - why do we want to waste space on > cache for a repo that is disabled? b/c the user didn't tell us to act on that repo. That's why. -sv From tmus at tmus.dk Thu Dec 8 22:36:34 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Thu, 08 Dec 2005 23:36:34 +0100 Subject: yum clean bug In-Reply-To: <1134081037.23944.58.camel@cutter> References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> <1134081037.23944.58.camel@cutter> Message-ID: seth vidal wrote: > On Thu, 2005-12-08 at 23:22 +0100, Thomas M Steenholdt wrote: >> How about repos that have been renamed or removed? Should we just accept >> that the cache for those repos will continue to waste space on our >> harddrives for eternity? > > you should accept that yum no longer has any information on those repos > or where their cache information is stored. > yum created that data in yum's cache directory - how can it not have information about those repos - yum should ask ls or something. Seriously though, yum's cache directory really should be considered yum's to handle. Other than that, we need to make tmpwatch monitor that directory too, by default since it really is a tmp directory that it's app does not care to clean up. /Thomas From skvidal at phy.duke.edu Thu Dec 8 22:48:56 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 08 Dec 2005 17:48:56 -0500 Subject: yum clean bug In-Reply-To: References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> <1134081037.23944.58.camel@cutter> Message-ID: <1134082136.23944.69.camel@cutter> > yum created that data in yum's cache directory - how can it not have > information about those repos - yum should ask ls or something. > Seriously though, yum's cache directory really should be considered > yum's to handle. _YOU_ can do that all you want. I'm not going to make assumptions about what users were intending when they disabled a repository in yum. When the repository is disabled we leave it the hell alone. That includes its cache. > Other than that, we need to make tmpwatch monitor that directory too, by > default since it really is a tmp directory that it's app does not care > to clean up. it's really not. But you can keep up with all the snide comments you want OR Here's where you can contribute. You could write a program to go through and clean out that data all you want. oh - but a word of warning - I've had a couple of different users tell me that b/c of bandwidth constraints they have one machine that downloads the packages into its cache then they nfs export their cache dir out to their other linux boxes. Hope you're program doesn't remove the data they INTENTIONALLY put there. -sv From nman64 at n-man.com Thu Dec 8 22:56:43 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Thu, 08 Dec 2005 16:56:43 -0600 Subject: yum clean bug In-Reply-To: <1134082136.23944.69.camel@cutter> References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> Message-ID: <4398BA2B.2040607@n-man.com> IMHO, yum is behaving exactly as it should. When I disable a repository, yum has no idea why I have done it, and should not disregard my wishes and change anything about that repository. As for repositories that no longer have configurations, I don't want yum making any assumptions there, either. I have no problems going in and cleaning out the cache manually if space becomes an issue. It would be easy enough to create a cron job to do the job. If someone wants to create a script to go along with yum-utils or to stand alone, I would see nothing wrong with that. I'm sure that would be a welcomed idea. I also wouldn't complain about a '--sanitize' option in yum, but the current behavior is what I would expect and want. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ -- Rate my assistance! http://rate.affero.net/nman64/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From strange at nsk.no-ip.org Thu Dec 8 22:59:37 2005 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Thu, 8 Dec 2005 22:59:37 +0000 Subject: yum clean bug In-Reply-To: <1134080580.23944.54.camel@cutter> References: <1134074565.23944.39.camel@cutter> <20051208205137.GA10102@nsk.no-ip.org> <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> <1134078696.1536.1.camel@weasel.turre.laiskiainen.org> <1134079174.23944.48.camel@cutter> <20051208221541.GC10102@nsk.no-ip.org> <1134080580.23944.54.camel@cutter> Message-ID: <20051208225937.GD10102@nsk.no-ip.org> On Thu, Dec 08, 2005 at 05:23:00PM -0500, seth vidal wrote: > On Thu, 2005-12-08 at 22:15 +0000, Luciano Miguel Ferreira Rocha wrote: > > > Bad analogies. We're talking about cache data. > > > > I don't even understand why is it necessary to gather repositories > > configuration. > > > > Don't forget that current behaviour makes it unable to delete cache for > > repositories no longer configurated. Unless by hand. > > > > > CLOSED->WONTFIX > Do you want me to fix it for you? Options: 1. yum clean ignores repo configuration and works at filesystem level only. 2. special case for --enablerepo="*" on yum clean, removing cache even for no longer defined repos. 3. new option --repo= for yum. Like --disablerepo="*" --enablerepo=arg, but yum clean by default works at filesystem level like 1. -- lfr 0/0 From jspaleta at gmail.com Thu Dec 8 23:01:22 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 8 Dec 2005 18:01:22 -0500 Subject: yum clean bug In-Reply-To: <1134082136.23944.69.camel@cutter> References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> Message-ID: <604aa7910512081501i6b1ffae6j84b939d2fa4c1ec@mail.gmail.com> On 12/8/05, seth vidal wrote: > oh - but a word of warning - I've had a couple of different users tell > me that b/c of bandwidth constraints they have one machine that > downloads the packages into its cache then they nfs export their cache > dir out to their other linux boxes. Yep I do this sort of thing on one network. a common share for the cache so all the fc4 machines that i admin cache packages to the same filesystem instead of having to regrab the same updates from the outside network. Some machines have updates-testing enabled.. some of them don't... but they all use the same cache tree. -jef From tmus at tmus.dk Thu Dec 8 23:03:00 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Fri, 09 Dec 2005 00:03:00 +0100 Subject: yum clean bug In-Reply-To: <1134081726.23944.61.camel@cutter> References: <1134074565.23944.39.camel@cutter> <20051208205137.GA10102@nsk.no-ip.org> <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> <1134078696.1536.1.camel@weasel.turre.laiskiainen.org> <1134079174.23944.48.camel@cutter> <1134081726.23944.61.camel@cutter> Message-ID: seth vidal wrote: > On Thu, 2005-12-08 at 23:19 +0100, Thomas M Steenholdt wrote: >> seth vidal wrote: >>> why on earth do you think yum should do what it's been told NOT to do? >>> >>> -sv >> the clean functions, to me, represents a way to make yum clean out it's >> stored data - it really has nothing to do with whether or not a repo is >> enabled, because the clean commands has nothing to do with repo >> intervention as such. just cleans out the cache. > > But how can I really be sure that ALL the data in that dir is > disposable, especially if the user has disabled the repo in question in > their config. If the repo is disabled - it means that the user don't care about that repo. Besides cache is always disposable, it serves a purpose but when we ask yum to clean out the cache it should just do it. next operation might take a little longer, but we asked for it (perhaps we needed an additional gig of freespace) and we are not losing any functionality whatsoever. (Wikipedia) In computer science, a *cache* is a collection of data *duplicating* original values stored elsewhere or computed earlier. we can't possible loose any vital information from pretty much just "rm -rf"-ing /var/cache/yum/*. Still yum should be the one to take care of this, not rm. you could add a noclean=1 option to exclude an existing repo from cleaning if you think that would serve any purpose at all. IMO that is not at all needed. > > I err on the side of protecting data. If yum is not told to remove it, > then it won't remove it. > How do you want me to tell yum that I want to remote repo XYZ when it does not exist anymore. > > >> A slightly different take is this - why do we want to waste space on >> cache for a repo that is disabled? > > b/c the user didn't tell us to act on that repo. > > That's why. > We told yum not to care about the repo - We did not tell yum to protect it. /Thomas From tmus at tmus.dk Thu Dec 8 23:11:19 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Fri, 09 Dec 2005 00:11:19 +0100 Subject: yum clean bug In-Reply-To: <604aa7910512081501i6b1ffae6j84b939d2fa4c1ec@mail.gmail.com> References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <604aa7910512081501i6b1ffae6j84b939d2fa4c1ec@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > On 12/8/05, seth vidal wrote: >> oh - but a word of warning - I've had a couple of different users tell >> me that b/c of bandwidth constraints they have one machine that >> downloads the packages into its cache then they nfs export their cache >> dir out to their other linux boxes. > > Yep I do this sort of thing on one network. a common share for the > cache so all the fc4 machines that i admin cache packages to the same > filesystem instead of having to regrab the same updates from the > outside network. Some machines have updates-testing enabled.. some of > them don't... but they all use the same cache tree. > > -jef > Are your repos disabled on these server systems? i don't suspect you're running yum clean all on them either way unless you really want to re-get it all? Also, IMO, this should be done as a mirror function (perhaps an idea for yum-utils) and stored elsewhere. as long as it's called a cache, it should be considered like that. Not something you want to count on is still there anyway. I understand the bandwidth limitation issue, but those repos are likely to be enabled anyway so a yum clean would do just as much damage on those systems. implement a noclean or protech option and we can all be happy. This would let yum know our intentions for disabling the repos. /Thomas From skvidal at phy.duke.edu Fri Dec 9 00:10:21 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 08 Dec 2005 19:10:21 -0500 Subject: yum clean bug In-Reply-To: References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <604aa7910512081501i6b1ffae6j84b939d2fa4c1ec@mail.gmail.com> Message-ID: <1134087021.28503.8.camel@cutter> > implement a noclean or protech option and we can all be happy. This > would let yum know our intentions for disabling the repos. no. we will NOT be implementing such code. -sv From skvidal at phy.duke.edu Fri Dec 9 00:10:53 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 08 Dec 2005 19:10:53 -0500 Subject: yum clean bug In-Reply-To: <20051208225937.GD10102@nsk.no-ip.org> References: <1134074565.23944.39.camel@cutter> <20051208205137.GA10102@nsk.no-ip.org> <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> <1134078696.1536.1.camel@weasel.turre.laiskiainen.org> <1134079174.23944.48.camel@cutter> <20051208221541.GC10102@nsk.no-ip.org> <1134080580.23944.54.camel@cutter> <20051208225937.GD10102@nsk.no-ip.org> Message-ID: <1134087053.28503.11.camel@cutter> > Do you want me to fix it for you? > > Options: > > 1. yum clean ignores repo configuration and works at filesystem level > only. > > 2. special case for --enablerepo="*" on yum clean, removing cache even > for no longer defined repos. > > 3. new option --repo= for yum. Like --disablerepo="*" --enablerepo=arg, > but yum clean by default works at filesystem level like 1. > CLOSED->WONTFIX we will NOT be doing this. Here ends the discussion. -sv From icon at fedoraproject.org Fri Dec 9 00:19:08 2005 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Thu, 08 Dec 2005 19:19:08 -0500 Subject: yum clean bug In-Reply-To: <20051208225937.GD10102@nsk.no-ip.org> References: <1134074565.23944.39.camel@cutter> <20051208205137.GA10102@nsk.no-ip.org> <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> <1134078696.1536.1.camel@weasel.turre.laiskiainen.org> <1134079174.23944.48.camel@cutter> <20051208221541.GC10102@nsk.no-ip.org> <1134080580.23944.54.camel@cutter> <20051208225937.GD10102@nsk.no-ip.org> Message-ID: <1134087548.2507.2.camel@localhost.localdomain> On Thu, 2005-08-12 at 22:59 +0000, Luciano Miguel Ferreira Rocha wrote: > 1. yum clean ignores repo configuration and works at filesystem level > only. cd /var/cache/yum for DIR in *; do if ! grep -q "[$DIR]" /etc/yum.repos.d/*.repo; then rm -rf $DIR fi done There you go. You can put it in your cron.weekly. Now can we move on? Regards, -- Konstantin Ryabitsev McGill University WSG Montr?al, Qu?bec From vd at paradigma.pt Fri Dec 9 00:43:48 2005 From: vd at paradigma.pt (Vitor Domingos) Date: Fri, 09 Dec 2005 00:43:48 +0000 Subject: rawhide report: 20051207 changes In-Reply-To: <200512071111.jB7BBiXL026956@porkchop.devel.redhat.com> References: <200512071111.jB7BBiXL026956@porkchop.devel.redhat.com> Message-ID: <4398D344.8030407@paradigma.pt> Build System wrote on 12/07/2005 11:12 AM: > > udev-076-1 > ---------- > * Tue Dec 06 2005 Harald Hoyer - 076-1 > - speedup udevd with selinux by calling matchpathcon_init_prefix() > - version 076 > I'm having problems again with USB mounts with this udev version. The 075 was fine... -- Vitor Domingos Paradigma.pt From strange at nsk.no-ip.org Fri Dec 9 00:58:33 2005 From: strange at nsk.no-ip.org (Luciano Miguel Ferreira Rocha) Date: Fri, 9 Dec 2005 00:58:33 +0000 Subject: yum clean bug In-Reply-To: <1134087548.2507.2.camel@localhost.localdomain> References: <1134074565.23944.39.camel@cutter> <20051208205137.GA10102@nsk.no-ip.org> <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> <1134078696.1536.1.camel@weasel.turre.laiskiainen.org> <1134079174.23944.48.camel@cutter> <20051208221541.GC10102@nsk.no-ip.org> <1134080580.23944.54.camel@cutter> <20051208225937.GD10102@nsk.no-ip.org> <1134087548.2507.2.camel@localhost.localdomain> Message-ID: <20051209005833.GA25020@nsk.no-ip.org> On Thu, Dec 08, 2005 at 07:19:08PM -0500, Konstantin Ryabitsev wrote: > On Thu, 2005-08-12 at 22:59 +0000, Luciano Miguel Ferreira Rocha wrote: > > 1. yum clean ignores repo configuration and works at filesystem level > > only. > > cd /var/cache/yum > for DIR in *; do > if ! grep -q "[$DIR]" /etc/yum.repos.d/*.repo; then > rm -rf $DIR > fi > done > > There you go. You can put it in your cron.weekly. > Now can we move on? No. I'm tired of contributing and volunteering my time to a project that ignores me. Best of luck to Fedora, Yum and Red Hat. -- lfr 0/0 From ndbecker2 at gmail.com Fri Dec 9 01:29:49 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 08 Dec 2005 20:29:49 -0500 Subject: yum clean bug References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> Message-ID: Patrick Barnes wrote: > IMHO, yum is behaving exactly as it should. When I disable a > repository, yum has no idea why I have done it, and should not disregard > my wishes and change anything about that repository. As for > repositories that no longer have configurations, I don't want yum making > any assumptions there, either. I have no problems going in and cleaning > out the cache manually if space becomes an issue. It would be easy > enough to create a cron job to do the job. If someone wants to create a > script to go along with yum-utils or to stand alone, I would see nothing > wrong with that. I'm sure that would be a welcomed idea. I also > wouldn't complain about a '--sanitize' option in yum, but the current > behavior is what I would expect and want. > Well, for the record, I disagree. Is there really any reason for disabling, except that the repo doesn't play nicely with others, so that I don't want it enabled by default? If so, why would I run clean all, and not want to clean it? The fact is, I have a couple of repos disabled by default, such as updates-testing. They had eaten lots of disk space. I did clean all. I certainly did not expect this behavior. If this is really the way we want it to act, please clearly document that we need to add --enablerepo=* to clean disabled repos. From denis at poolshark.org Fri Dec 9 01:49:27 2005 From: denis at poolshark.org (Denis Leroy) Date: Thu, 08 Dec 2005 17:49:27 -0800 Subject: yum clean bug In-Reply-To: References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> Message-ID: <4398E2A7.5030102@poolshark.org> Neal Becker wrote: > Patrick Barnes wrote: > > >>IMHO, yum is behaving exactly as it should. When I disable a >>repository, yum has no idea why I have done it, and should not disregard >>my wishes and change anything about that repository. As for >>repositories that no longer have configurations, I don't want yum making >>any assumptions there, either. I have no problems going in and cleaning >>out the cache manually if space becomes an issue. It would be easy >>enough to create a cron job to do the job. If someone wants to create a >>script to go along with yum-utils or to stand alone, I would see nothing >>wrong with that. I'm sure that would be a welcomed idea. I also >>wouldn't complain about a '--sanitize' option in yum, but the current >>behavior is what I would expect and want. >> > > Well, for the record, I disagree. Is there really any reason for disabling, > except that the repo doesn't play nicely with others, so that I don't want > it enabled by default? If so, why would I run clean all, and not want to > clean it? > > The fact is, I have a couple of repos disabled by default, such as > updates-testing. They had eaten lots of disk space. I did clean all. I > certainly did not expect this behavior. If this is really the way we want > it to act, please clearly document that we need to add --enablerepo=* to > clean disabled repos. +1. Only cleaning enabled repositories seems very counter intuitive. From bbbush.yuan at gmail.com Fri Dec 9 01:54:16 2005 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Fri, 9 Dec 2005 09:54:16 +0800 Subject: yum clean bug In-Reply-To: References: <1134074565.23944.39.camel@cutter> <20051208205137.GA10102@nsk.no-ip.org> <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> <1134078696.1536.1.camel@weasel.turre.laiskiainen.org> <1134079174.23944.48.camel@cutter> <1134081726.23944.61.camel@cutter> Message-ID: <76e72f800512081754m71dca3deg@mail.gmail.com> 2005/12/9, Thomas M Steenholdt : > > If the repo is disabled - it means that the user don't care about that > repo. Besides cache is always disposable, it serves a purpose but when No, you are the user but I'm not. People tends to be "the user" when they are talking about themselves. -- bbbush ^_^ From ndbecker2 at gmail.com Fri Dec 9 01:57:23 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Thu, 08 Dec 2005 20:57:23 -0500 Subject: yum clean bug References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> Message-ID: Denis Leroy wrote: > Neal Becker wrote: >> Patrick Barnes wrote: >> >> >>>IMHO, yum is behaving exactly as it should. When I disable a >>>repository, yum has no idea why I have done it, and should not disregard >>>my wishes and change anything about that repository. As for >>>repositories that no longer have configurations, I don't want yum making >>>any assumptions there, either. I have no problems going in and cleaning >>>out the cache manually if space becomes an issue. It would be easy >>>enough to create a cron job to do the job. If someone wants to create a >>>script to go along with yum-utils or to stand alone, I would see nothing >>>wrong with that. I'm sure that would be a welcomed idea. I also >>>wouldn't complain about a '--sanitize' option in yum, but the current >>>behavior is what I would expect and want. >>> >> >> Well, for the record, I disagree. Is there really any reason for >> disabling, except that the repo doesn't play nicely with others, so that >> I don't want >> it enabled by default? If so, why would I run clean all, and not want to >> clean it? >> >> The fact is, I have a couple of repos disabled by default, such as >> updates-testing. They had eaten lots of disk space. I did clean all. I >> certainly did not expect this behavior. If this is really the way we >> want it to act, please clearly document that we need to add >> --enablerepo=* to clean disabled repos. > > +1. Only cleaning enabled repositories seems very counter intuitive. > > > I guess the question comes down to, what do I mean by "disabled"? According to the proposed model, "disabled" means _everything_ is disabled. What I, and I believe many others want, is disable installing. Perhaps "disabled" should be split into multiple options? disable-install, disable-clean, etc? From jspaleta at gmail.com Fri Dec 9 02:55:18 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 8 Dec 2005 21:55:18 -0500 Subject: yum clean bug In-Reply-To: References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> Message-ID: <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> On 12/8/05, Neal Becker wrote: > Perhaps "disabled" should be split into multiple options? disable-install, > disable-clean, etc? dear god... that level of command granularity is madness.. absolute madness. +1 for adding text in the manpage which states that if you want to clean to act on all configured repositories to --enablerepo=* during clean operations. -jef"snow before morning rush hour good... snow during morning rush hour bad"spaleta From johnp at redhat.com Fri Dec 9 03:59:08 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Thu, 08 Dec 2005 22:59:08 -0500 Subject: gstreamer 0.10 In-Reply-To: References: Message-ID: <1134100748.11873.9.camel@localhost.localdomain> On Thu, 2005-12-08 at 13:54 -0600, Jason Dravet wrote: > Is gstreamer 0.10 going to be in FC5T2? That depends if we have applications that are ported to it. As it is I would say that it should go into extras first. If a significant portion of core apps start depending on 0.10 then we can pull it in. -- John (J5) Palmieri From jkeating at j2solutions.net Fri Dec 9 04:57:06 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 08 Dec 2005 21:57:06 -0700 Subject: yum clean bug In-Reply-To: <20051209005833.GA25020@nsk.no-ip.org> References: <1134074565.23944.39.camel@cutter> <20051208205137.GA10102@nsk.no-ip.org> <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> <1134078696.1536.1.camel@weasel.turre.laiskiainen.org> <1134079174.23944.48.camel@cutter> <20051208221541.GC10102@nsk.no-ip.org> <1134080580.23944.54.camel@cutter> <20051208225937.GD10102@nsk.no-ip.org> <1134087548.2507.2.camel@localhost.localdomain> <20051209005833.GA25020@nsk.no-ip.org> Message-ID: <1134104226.3423.3.camel@ender> On Fri, 2005-12-09 at 00:58 +0000, Luciano Miguel Ferreira Rocha wrote: > > No. I'm tired of contributing and volunteering my time to a project that > ignores me. > > Best of luck to Fedora, Yum and Red Hat. We don't ignore you. In fact, you have been having a discussion. Ignoring you would mean that your post would have never been acted upon. You requested a feature, the upstream developer for the software in question doesn't agree that this feature should be in the software. End of discussion. Feel free to fork yum if you really think you need the feature, and then try to convince other folks to use your fork. Now if we were ignoring you, you would request it many times, maybe even file an RFE in various bugzillas, that would sit untouched for time out of mind. That didn't happen here did it? So now you're going to run off in a huff because the upstream developer doesn't agree with your feature request? You're going to be running from a lot of things if you continue like that. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From nman64 at n-man.com Fri Dec 9 05:24:33 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Thu, 08 Dec 2005 23:24:33 -0600 Subject: yum clean bug In-Reply-To: <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> Message-ID: <43991511.4020705@n-man.com> Jeff Spaleta wrote: > On 12/8/05, Neal Becker wrote: > > Perhaps "disabled" should be split into multiple options? disable-install, > > disable-clean, etc? > > > dear god... that level of command granularity is madness.. absolute madness. > > +1 > for adding text in the manpage which states that if you want to clean > to act on all configured repositories to --enablerepo=* during clean > operations. > > -jef"snow before morning rush hour good... snow during morning rush > hour bad"spaleta > > There are *exactly* two courses of action I would stand behind: 1. Improving documentation to cover what 'yum clean' is and is not. Including further directions for those who want a sterile cache would be sensible. 2. Creating a separate tool or adding the capability to yum to 'sanitize' the cache folder, which would mean *completely* cleaning it out. #1 is easy enough. Anyone can do this, and it would take less effort than continuing this discussion. #2 is just a matter of where it should go. If Seth feels really nice, it might be able to go into yum as a command (eg. 'yum sanitize' or 'yum clean --sanitize'), but otherwise would need to be created as a plugin or separate tool (possibly to be included in yum-utils). This option would still be well-served by #1. I personally don't have time to undertake this, but I'd be happy to advise anyone who is to the best of my abilities. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ -- Rate my assistance! http://rate.affero.net/nman64/ -------------- 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 j2solutions.net Fri Dec 9 05:34:54 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 08 Dec 2005 22:34:54 -0700 Subject: yum clean bug In-Reply-To: <43991511.4020705@n-man.com> References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <43991511.4020705@n-man.com> Message-ID: <1134106494.3423.19.camel@ender> On Thu, 2005-12-08 at 23:24 -0600, Patrick Barnes wrote: > 2. Creating a separate tool or adding the capability to yum to > 'sanitize' the cache folder, which would mean *completely* cleaning it out. > You mean rm -rf /var/cache/yum/* ? Cleans out everything, to be recreated upon calling yum again. Do we really need to make a tool to do this? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From tmus at tmus.dk Fri Dec 9 06:14:25 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Fri, 09 Dec 2005 07:14:25 +0100 Subject: yum clean bug In-Reply-To: <76e72f800512081754m71dca3deg@mail.gmail.com> References: <1134074565.23944.39.camel@cutter> <20051208205137.GA10102@nsk.no-ip.org> <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> <1134078696.1536.1.camel@weasel.turre.laiskiainen.org> <1134079174.23944.48.camel@cutter> <1134081726.23944.61.camel@cutter> <76e72f800512081754m71dca3deg@mail.gmail.com> Message-ID: Yuan Yijun wrote: > 2005/12/9, Thomas M Steenholdt : >> If the repo is disabled - it means that the user don't care about that >> repo. Besides cache is always disposable, it serves a purpose but when > > No, you are the user but I'm not. People tends to be "the user" when > they are talking about themselves. > > -- > bbbush ^_^ > Please take the time to read through the previous post. I'm specificly suggesting adding a new option that would actually make yum know why our repo is disabled, to counter anybodys reason for disabling the repo. unknown repos, should still, IMO, have their caches removed, no questions asked. Ah well. Not the end of the world - I guess i'll have to settle for a locally decided cleanup thing here. /Thomas From tmus at tmus.dk Fri Dec 9 06:21:28 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Fri, 09 Dec 2005 07:21:28 +0100 Subject: yum clean bug In-Reply-To: <1134106494.3423.19.camel@ender> References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <43991511.4020705@n-man.com> <1134106494.3423.19.camel@ender> Message-ID: Jesse Keating wrote: > On Thu, 2005-12-08 at 23:24 -0600, Patrick Barnes wrote: >> 2. Creating a separate tool or adding the capability to yum to >> 'sanitize' the cache folder, which would mean *completely* cleaning it out. >> > > You mean rm -rf /var/cache/yum/* ? Cleans out everything, to be > recreated upon calling yum again. Do we really need to make a tool to > do this? > Either that or just put in the CLEAN section of the man page that this is required for disabled and non-existing repos. /Thomas From mukund.miscregisters at gmail.com Fri Dec 9 07:13:28 2005 From: mukund.miscregisters at gmail.com (mukund jampala) Date: Fri, 9 Dec 2005 12:43:28 +0530 Subject: FC4 Hangs when copying more that 40MB to SD card..why? Message-ID: Dear Fedora Developers, I have tested my SD card driver on the following version of Fedora Distributions. Fedora Core 2/ 3/ 4 I have tried till the range of 512 MB on Fedora Core 2/ 3/ 4. Except FC4 all other kernels had no problem copying the files above 40MB to the Flash Media devices. Is there any thing new in the FC4 kernel I am required to ahndle in the driver? Can someone please through some light on this Problem? Regards, Mukund Jampala From nicolas.mailhot at laposte.net Fri Dec 9 07:43:06 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 09 Dec 2005 08:43:06 +0100 Subject: yum clean bug In-Reply-To: <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> Message-ID: <4399358A.2060005@laposte.net> Jeff Spaleta wrote: > On 12/8/05, Neal Becker wrote: >> Perhaps "disabled" should be split into multiple options? disable-install, >> disable-clean, etc? > > > dear god... that level of command granularity is madness.. absolute madness. > > +1 > for adding text in the manpage which states that if you want to clean > to act on all configured repositories to --enablerepo=* during clean > operations. If you've asked "all" in the first place that was precisely to nuke everything no questions asked. You didn't ask about particular repos, you asked yum to clean all its temp data Also, the FHS states clearly : ? /var/cache is intended for cached data from applications. Such data is locally generated as a result of time-consuming I/O or calculation. The application must be able to regenerate or restore the data. Unlike /var/spool, the cached files can be deleted without data loss. ? So if the yum cache must be preserved to prevent data loss (as Seth writes), it has no place in /var/cache. It can be nucked at any time by yum or something else (? The application must always be able to recover from manual deletion of these files (generally because of a disk space shortage ?). yum clean all behaviour may be familiar to yum developpers, but it's contrary to both English (all is no longer everything) and accepted Linux standards (cache is no longer disposable) -- Nicolas Mailhot From seanlkml at sympatico.ca Fri Dec 9 07:50:52 2005 From: seanlkml at sympatico.ca (Sean) Date: Fri, 9 Dec 2005 02:50:52 -0500 (EST) Subject: yum clean bug In-Reply-To: <1134087548.2507.2.camel@localhost.localdomain> References: <1134074565.23944.39.camel@cutter> <20051208205137.GA10102@nsk.no-ip.org> <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> <1134078696.1536.1.camel@weasel.turre.laiskiainen.org> <1134079174.23944.48.camel@cutter> <20051208221541.GC10102@nsk.no-ip.org> <1134080580.23944.54.camel@cutter> <20051208225937.GD10102@nsk.no-ip.org> <1134087548.2507.2.camel@localhost.localdomain> Message-ID: On Thu, December 8, 2005 7:19 pm, Konstantin Ryabitsev said: > cd /var/cache/yum > for DIR in *; do > if ! grep -q "[$DIR]" /etc/yum.repos.d/*.repo; then > rm -rf $DIR > fi > done > > There you go. You can put it in your cron.weekly. This script is a bit fragile. There will be bad consequences if /var/cache/yum goes missing for whatever reason; it's likely to wipe out your entire filesystem. Better to fail rather than proceed if the "cd" fails. Even with that fixed the script could do unintended things if any of the directories happen to have a space in them because $DIR isn't properly quoted. Sean From nman64 at n-man.com Fri Dec 9 08:15:06 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Fri, 09 Dec 2005 02:15:06 -0600 Subject: yum clean bug In-Reply-To: <4399358A.2060005@laposte.net> References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <4399358A.2060005@laposte.net> Message-ID: <43993D0A.3050602@n-man.com> Nicolas Mailhot wrote: > Jeff Spaleta wrote: > > On 12/8/05, Neal Becker wrote: > >> Perhaps "disabled" should be split into multiple options? disable-install, > >> disable-clean, etc? > > > > > > dear god... that level of command granularity is madness.. absolute madness. > > > > +1 > > for adding text in the manpage which states that if you want to clean > > to act on all configured repositories to --enablerepo=* during clean > > operations. > > If you've asked "all" in the first place that was precisely to nuke > everything no questions asked. You didn't ask about particular repos, > you asked yum to clean all its temp data > > Also, the FHS states clearly : > > ? /var/cache is intended for cached data from applications. Such data is > locally generated as a result of time-consuming I/O or calculation. The > application must be able to regenerate or restore the data. Unlike > /var/spool, the cached files can be deleted without data loss. ? > > So if the yum cache must be preserved to prevent data loss (as Seth > writes), it has no place in /var/cache. It can be nucked at any time by > yum or something else (? The application must always be able to recover > from manual deletion of these files (generally because of a disk space > shortage ?). > > yum clean all behaviour may be familiar to yum developpers, but it's > contrary to both English (all is no longer everything) and accepted > Linux standards (cache is no longer disposable) > > If I intentionally protect my web browser's cache from deletion through some reconfiguration in order to audit the cache, maintain certain cached content to speed up a future process, etc., that doesn't change the fact that it is cached, and I wouldn't want my browser to ignore me and erase it. If I've disabled a repository, that means I'm telling yum to forget about it. The same is true if I delete the configuration. This is not a violation of standards. It isn't a violation of English, either. When I use 'yum clean all', I'm telling yum to 'clean all of that cached data in the enabled repositories'. Not that any of this is relevant. The point is moot. You're beating a dead horse. The options lie before you, and I'm sincerely sorry if you disagree with the decision, but we need to move on. This isn't worth it. You're welcome to do anything within your power to solve the problem in your eyes. You're welcome, in fact, to download the source code to yum and modify it to do your bidding. If you really feel like helping others who feel the way you do, you can improve the documentation for yum to make its operation more clear. You could also write a tool/script/plugin to do whatever you like, and can then submit that item to Extras or ask that it be included in an existing package (yum-utils). Don't pointlessly drag out this thread. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ -- Rate my assistance! http://rate.affero.net/nman64/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From sundaram at redhat.com Fri Dec 9 08:26:45 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 09 Dec 2005 13:56:45 +0530 Subject: yum clean bug In-Reply-To: References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> Message-ID: <43993FC5.2010303@redhat.com> HI >Well, for the record, I disagree. Is there really any reason for disabling, >except that the repo doesn't play nicely with others, so that I don't want >it enabled by default? If so, why would I run clean all, and not want to >clean it? > Repositories are disabled for several different reasons. For example if I am using a set of 5 repositories which are perfectly compatible with each other but the large majority of packages are in 2 of these repositories then it makes sense to enable them on demand rather than slow down yum repository checking everytime. I could have configured custom repositories I rarely use. Its not safe to assume that the user doesnt care about disable repositories at all. regards Rahul From sundaram at redhat.com Fri Dec 9 08:29:54 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 09 Dec 2005 13:59:54 +0530 Subject: yum clean bug In-Reply-To: <20051209005833.GA25020@nsk.no-ip.org> References: <1134074565.23944.39.camel@cutter> <20051208205137.GA10102@nsk.no-ip.org> <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> <1134078696.1536.1.camel@weasel.turre.laiskiainen.org> <1134079174.23944.48.camel@cutter> <20051208221541.GC10102@nsk.no-ip.org> <1134080580.23944.54.camel@cutter> <20051208225937.GD10102@nsk.no-ip.org> <1134087548.2507.2.camel@localhost.localdomain> <20051209005833.GA25020@nsk.no-ip.org> Message-ID: <43994082.1000503@redhat.com> Hi >No. I'm tired of contributing and volunteering my time to a project that >ignores me. > >Best of luck to Fedora, Yum and Red Hat. > > > The upstream developer for a software that Fedora uses disagrees with your opinion on how a particular functionality should be implemented. This is not ignoring you. If you would like to contribute there are several other ways to do so. Yum-utils or a separate package might be used. There are several other sub projects within Fedora too. If you are going to quit just because a particular developer disagreed with you its probably hard to coordinate on any project at all. regards Rahul From pmatilai at laiskiainen.org Fri Dec 9 09:02:36 2005 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Fri, 9 Dec 2005 01:02:36 -0800 (PST) Subject: yum clean bug In-Reply-To: References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> Message-ID: On Thu, 8 Dec 2005, Neal Becker wrote: > > Well, for the record, I disagree. Is there really any reason for disabling, > except that the repo doesn't play nicely with others, so that I don't want > it enabled by default? If so, why would I run clean all, and not want to > clean it? Yup, I really don't see what's there to "protect" in cached data from somewhere. It's not like where talking about personal documents and such... > > The fact is, I have a couple of repos disabled by default, such as > updates-testing. They had eaten lots of disk space. I did clean all. I > certainly did not expect this behavior. This is precisely the reason I dislike the current behavior - if I ask yum to "clean all" I really expect it to clean ALL of the cache and not leave old junk from disabled repos around, eating disk space. > If this is really the way we want it to act, please clearly document > that we need to add --enablerepo=* to clean disabled repos. I guess can live with that, it just feels rather counterintuitive to me to have to mess with repo settings to clean cache data. If somebody can come up with a real, sane usage scenario why leaving disabled repos alone on clean operations is a good idea it might help making it feel a bit less odd. :) - Panu - From alan at redhat.com Fri Dec 9 09:37:04 2005 From: alan at redhat.com (Alan Cox) Date: Fri, 9 Dec 2005 04:37:04 -0500 Subject: yum clean bug In-Reply-To: <1134087053.28503.11.camel@cutter> References: <1134074565.23944.39.camel@cutter> <20051208205137.GA10102@nsk.no-ip.org> <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> <1134078696.1536.1.camel@weasel.turre.laiskiainen.org> <1134079174.23944.48.camel@cutter> <20051208221541.GC10102@nsk.no-ip.org> <1134080580.23944.54.camel@cutter> <20051208225937.GD10102@nsk.no-ip.org> <1134087053.28503.11.camel@cutter> Message-ID: <20051209093704.GA30811@devserv.devel.redhat.com> On Thu, Dec 08, 2005 at 07:10:53PM -0500, seth vidal wrote: > CLOSED->WONTFIX > > we will NOT be doing this. Here ends the discussion. Don't you mean CLOSED->GO FORK Alan From ralph+fedora at strg-alt-entf.org Fri Dec 9 10:26:56 2005 From: ralph+fedora at strg-alt-entf.org (Ralph Angenendt) Date: Fri, 9 Dec 2005 11:26:56 +0100 Subject: yum clean bug In-Reply-To: References: <1134074565.23944.39.camel@cutter> <20051208205137.GA10102@nsk.no-ip.org> <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> <1134078696.1536.1.camel@weasel.turre.laiskiainen.org> <1134079174.23944.48.camel@cutter> <1134081726.23944.61.camel@cutter> <76e72f800512081754m71dca3deg@mail.gmail.com> Message-ID: <20051209102656.GC7457@br-online.de> Thomas M Steenholdt wrote: > unknown repos, should still, IMO, have their caches removed, no > questions asked. How is yum supposed to know, that this is data from a repository, if there's no configuration for the repository anymore? Just because it lives under /var/cache/yum? Ralph -- Ralph Angenendt......ra at br-online.de | .."Text processing has made it possible Bayerischer Rundfunk...HA-Multimedia | ....to right-justify any idea, even one Rundfunkplatz 1........80300 M?nchen | .which cannot be justified on any other Tl:089.5900.16023..Fx:089.5900.16240 | ..........grounds." -- J. Finnegan, USC -------------- 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 Fri Dec 9 10:33:36 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 9 Dec 2005 11:33:36 +0100 (CET) Subject: yum clean bug In-Reply-To: <20051209102656.GC7457@br-online.de> References: <1134074565.23944.39.camel@cutter> <20051208205137.GA10102@nsk.no-ip.org> <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> <1134078696.1536.1.camel@weasel.turre.laiskiainen.org> <1134079174.23944.48.camel@cutter> <1134081726.23944.61.camel@cutter> <76e72f800512081754m71dca3deg@mail.gmail.com> <20051209102656.GC7457@br-online.de> Message-ID: <59111.192.54.193.25.1134124416.squirrel@rousalka.dyndns.org> On Ven 9 d?cembre 2005 11:26, Ralph Angenendt wrote: > Thomas M Steenholdt wrote: >> unknown repos, should still, IMO, have their caches removed, no >> questions asked. > > How is yum supposed to know, that this is data from a repository, if > there's no configuration for the repository anymore? Just because it > lives under /var/cache/yum? Yes. That's the whole point of having an app-specific dir. Alternatively if yum wants a persistent cache, it should be moved to /var/spool -- Nicolas Mailhot From dwmw2 at infradead.org Fri Dec 9 10:37:07 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 09 Dec 2005 11:37:07 +0100 Subject: FC4 Hangs when copying more that 40MB to SD card..why? In-Reply-To: References: Message-ID: <1134124628.19711.104.camel@localhost.localdomain> On Fri, 2005-12-09 at 12:43 +0530, mukund jampala wrote: > Is there any thing new in the FC4 kernel I am required to ahndle in > the driver? > Can someone please through some light on this Problem? You didn't include a link to the source code of your driver -- how can we see what you're doing wrong if you didn't show us? -- dwmw2 From tmus at tmus.dk Fri Dec 9 10:46:15 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Fri, 09 Dec 2005 11:46:15 +0100 Subject: yum clean bug In-Reply-To: <59111.192.54.193.25.1134124416.squirrel@rousalka.dyndns.org> References: <1134074565.23944.39.camel@cutter> <20051208205137.GA10102@nsk.no-ip.org> <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> <1134078696.1536.1.camel@weasel.turre.laiskiainen.org> <1134079174.23944.48.camel@cutter> <1134081726.23944.61.camel@cutter> <76e72f800512081754m71dca3deg@mail.gmail.com> <20051209102656.GC7457@br-online.de> <59111.192.54.193.25.1134124416.squirrel@rousalka.dyndns.org> Message-ID: Nicolas Mailhot wrote: > On Ven 9 d?cembre 2005 11:26, Ralph Angenendt wrote: >> Thomas M Steenholdt wrote: >>> unknown repos, should still, IMO, have their caches removed, no >>> questions asked. >> How is yum supposed to know, that this is data from a repository, if >> there's no configuration for the repository anymore? Just because it >> lives under /var/cache/yum? > > Yes. That's the whole point of having an app-specific dir. > Alternatively if yum wants a persistent cache, it should be moved to > /var/spool > I have to agree with this completely! That said, /var/spool stuff should not just be left there for good either. If there are things in yum's cache dir that yum does not know about, by all means, get rid if it at first given chance. /Thomas From mailinglists at erwinrol.com Fri Dec 9 10:51:34 2005 From: mailinglists at erwinrol.com (Erwin Rol) Date: Fri, 09 Dec 2005 11:51:34 +0100 Subject: Broken video drivers in new modular X In-Reply-To: <1132564932.8267.20.camel@xpc.home.erwinrol.com> References: <1132564932.8267.20.camel@xpc.home.erwinrol.com> Message-ID: <1134125494.14221.12.camel@xpc.home.erwinrol.com> The radeon driver is still broken, and only works without acceleration (anything else causes hard lockup of the whole machine). Will Xorg 7.0.0R3 be available for rawhide ? - Erwin On Mon, 2005-11-21 at 10:22 +0100, Erwin Rol wrote: > On Mon, 2005-11-21 at 02:44 -0500, Sadda Teh wrote: > > Hi all, just writing to say that on my Dell Inspiron 8000 laptop > > (latest BIOS) with ATI Mobility M4 video the modular X vesa and r128 > > drivers do not work properly. > > My Radeon locks the machine hard, meaning no network, no nothing, only > can press the reset/power switch. I have seen previous reports here with > the same problem, but there was talk about that AGP might be the > problem, but i have a PCIe card (01:00.0 VGA compatible controller: ATI > Technologies Inc RV370 5B60 [Radeon X300 (PCIE)] ). > That card worked fine with the old Xorg before the switch to mod-X. > > > When X is configured to use the vesa driver it comes up, but the > > picture is distorted (looks like 2 vertical desktops overlapping one > > another at various points, also colors are messed up). > > When i use the vesa driver i see things like that too. The icons of > applications have the wrong colors (looks like R and G and B are > switched) and they are also at the wrong place (shifted 20 pixels or > so). > > I am now running with the fbdev driver on top of the radeonfb this works > but is of course not optimal. > > > As for trying to use the r128 driver, X cannot even load when > > configured this way, it fails with an error along the lines of the > > r128_drv.so could not be opened. Has anyone else seen issues like this > > with the new modular X packages? Should I file bugs for these in > > x.org's bugzilla? Thanks. > > Well if it are really the same issues i dunno, but i sure have issues > with mod X. > > - Erwin > > From buildsys at redhat.com Fri Dec 9 11:16:20 2005 From: buildsys at redhat.com (Build System) Date: Fri, 9 Dec 2005 06:16:20 -0500 Subject: rawhide report: 20051209 changes Message-ID: <200512091116.jB9BGK07025910@porkchop.devel.redhat.com> Updated Packages: anaconda-10.90.15-1 ------------------- * Thu Dec 08 2005 Jeremy Katz - 10.90.15-1 - Fix various typos in the new group selection code (clumens) - Support bytesPerInode on RAID (Curtis Doty, #175288) - Stub some more for the loader to fix line-drawing chars again - Handle file read failures better (pnasrat) - Initial support for upgrades again (pnasrat) - Minor padding tweaks to the UI * Thu Dec 08 2005 Jeremy Katz - 10.90.14-1 - Fix up for moved x locale data - Remove vnc hack now that VNC knows where to look for fonts - Don't go to text mode for no mouse (notting) - Update to work with yum 2.5.0 cvs snap - New package selection code - Add new chinese font back now that we're using squashfs (#172163) - The return of locale-archive usage * Mon Dec 05 2005 Chris Lumens 10.90.13-1 - Reword media check dialog (dcantrell, #174530). - gcc41 compile fixes (pjones). - Add genhomedircon, setfiles, and /etc/shells for selinux. apr-1.2.2-4 ----------- * Thu Dec 08 2005 Joe Orton 1.2.2-4 - add apr_file_seek() fixes from upstream (r326593, r326597) bash-3.0-40 ----------- * Thu Dec 08 2005 Tim Waugh 3.0-40 - Fix read memleak when reading from non-blocking fd (bug #173283). - Missed another loop for improved sighandler patch (bug #169231). * Wed Dec 07 2005 Tim Waugh 3.0-39 - Missed a loop for improved sighandler patch (bug #169231). * Tue Dec 06 2005 Tim Waugh 3.0-38 - Test out improved sighandler patch (bug #169231). firstboot-1.3.55-1 ------------------ * Thu Dec 08 2005 Chris Lumens 1.3.55-1 - Fix grammar problems (#143953). - Fix traceback on user screen (#175227). gcc-4.1.0-0.6 ------------- * Wed Dec 07 2005 Jakub Jelinek 4.1.0-0.6 - allow #pragmas at C struct scope as well as ObjC class scope (PR c/25246) - some gomp testcase fixes * Wed Dec 07 2005 Jakub Jelinek 4.1.0-0.5 - update from gcc-4_1-branch (-r107810:108157) - PRs bootstrap/25207, c++/24103, c++/24138, c++/24173, fortran/15809, fortran/21302, fortran/23912, java/25283, libfortran/24919, libgfortran/25149, middle-end/25176, other/13873, target/18580, target/24108, target/24475, target/24934, target/25199, testsuite/25247, tree-optimization/24963 - update from gomp-20050608-branch (up to -r108105) - -Wstrict-aliasing C++ support (Richard Guenther, Dirk Mueller, Paolo Carlini, PRs c++/14024, libstdc++/24975) - fix mark_used_regs regression (Andreas Krebbel, PR rtl-optimization/24823) - fix reload ICE (Kaz Kojima, PR target/24982) - fix PPC ICE on Linux kernel (Paolo Bonzini, PR target/24982) - fix s390{,x} shifts with shift count ANDed with constant mask (Andreas Krebbel, PR target/25268) - s390{,x} atomic builtins enhancements (Adrian Straetling) * Thu Dec 01 2005 Jakub Jelinek 4.1.0-0.4 - update from gcc-4_1-branch (-r107618:107810) - PRs c++/21123, c++/21166, fortran/24223, fortran/24705, java/18278, libgfortran/25109, middle-end/20109, middle-end/25120, middle-end/25158, rtl-opt/24930 - use %{_tmppath} in BuildRoot (#174594) - require libgomp in gcc subpackage - fix Java .so symlinks gjdoc-0.7.6-2 ------------- * Fri Dec 09 2005 Warren Togami 0.7.6-2 - rebuild with gcc-4.1 grub-0.95-17 ------------ * Mon Dec 05 2005 Peter Jones - 0.95-17 - fix configure conftest.c bugs - add -Wno-unused to defeat gcc41 "unused" checking when there are aliases. java-1.4.2-gcj-compat-0:1.4.2.0-40jpp_56rh ------------------------------------------ * Wed Nov 30 2005 Thomas Fitzsimmons - 0:1.4.2.0-40jpp_56rh - Bump release number. jessie-0:1.0.0-10 ----------------- * Thu Dec 08 2005 Thomas Fitzsimmons 0:1.0.0-10 - Bump release number. jpackage-utils-0:1.6.3-1jpp_2rh ------------------------------- * Wed Nov 30 2005 Thomas Fitzsimmons 0:1.6.3-1jpp_2rh - Bump release number. kernel-2.6.14-1.1749_FC5 ------------------------ * Thu Dec 08 2005 David Woodhouse - Clean up Cell patches, make it boot on real hardware libselinux-1.29.1-1 ------------------- * Thu Dec 08 2005 Dan Walsh 1.29.1-1 - Update to never version * Merged patch for swig interfaces from Dan Walsh. libsemanage-1.4-1 ----------------- * Wed Dec 07 2005 Dan Walsh 1.4-1 - Fix mode of output seusers file libtool-1.5.20-5 ---------------- * Wed Nov 30 2005 Warren Togami 1.5.20-5 - rebuilt with GCC 4.1.0 libwpd-0.8.4-1 -------------- * Fri Dec 02 2005 Caolan McNamara 0.8.4-1 - next version man-pages-2.16-1 ---------------- * Thu Dec 08 2005 Ivana Varekova 2.16-1 - update to 2.16 * Thu Nov 10 2005 Ivana Varekova 2.13-1 - update to 2.13 * Mon Oct 10 2005 Ivana Varekova 2.08-1 - update to 2.08 oprofile-0.9.1-6 ---------------- * Mon Dec 05 2005 Will Cohen - Correct anon namespace issue. php-5.1.1-5 ----------- * Thu Dec 08 2005 Joe Orton 5.1.1-5 - require net-snmp for php-snmp (#174800) policycoreutils-1.29.1-1 ------------------------ * Thu Dec 08 2005 Dan Walsh 1.29.1-1 - Update to match NSA * Merged fix for audit2allow long option list from Dan Walsh. * Merged -r option for restorecon (alias for -R) from Dan Walsh. * Merged chcat script and man page from Dan Walsh. * Wed Dec 07 2005 Dan Walsh 1.28-1 - Update to match NSA - Add gfs support pykickstart-0.10-1 ------------------ * Thu Dec 08 2005 Chris Lumens 0.10-1 - Support --bytes-per-inode on raid (Curtis Doty #175288). selinux-policy-2.1.1-1 ---------------------- * Thu Dec 08 2005 Dan Walsh 2.1.1-1 - Update to upstream - Turn off boolean allow_execstack * Thu Dec 08 2005 Dan Walsh 2.1.0-3 - Change setrans-mls to use new libsetrans - Add default_context rule for xdm * Thu Dec 08 2005 Dan Walsh 2.1.0-2. - Change Requires to PreReg for requiring of policycoreutils on install system-config-date-1.7.99.9-1 ----------------------------- * Thu Dec 08 2005 Nils Philippsen 1.7.99.9 - draw frame around highlighted region system-config-securitylevel-1.6.12-1 ------------------------------------ * Thu Dec 08 2005 Chris Lumens 1.6.12-1 - Write out selinux config file (#174104). vim-1:6.4.004-1 --------------- * Thu Dec 08 2005 Karsten Hopp 6.4.004-1 - fix fstab syntax file (#174735) - patchlevel 4 vnc-4.1.1-30 ------------ * Thu Dec 08 2005 Tim Waugh 4.1.1-30 - Enable Xdmcp (bug #175298). Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 ant - 1.6.5-0jpp_1fc.i386 requires libgcj.so.6 ant-antlr - 1.6.5-0jpp_1fc.i386 requires libgcj.so.6 ant-apache-bcel - 1.6.5-0jpp_1fc.i386 requires libgcj.so.6 ant-apache-bsf - 1.6.5-0jpp_1fc.i386 requires libgcj.so.6 ant-apache-log4j - 1.6.5-0jpp_1fc.i386 requires libgcj.so.6 ant-apache-oro - 1.6.5-0jpp_1fc.i386 requires libgcj.so.6 ant-apache-regexp - 1.6.5-0jpp_1fc.i386 requires libgcj.so.6 ant-apache-resolver - 1.6.5-0jpp_1fc.i386 requires libgcj.so.6 ant-commons-logging - 1.6.5-0jpp_1fc.i386 requires libgcj.so.6 ant-javamail - 1.6.5-0jpp_1fc.i386 requires libgcj.so.6 ant-jdepend - 1.6.5-0jpp_1fc.i386 requires libgcj.so.6 ant-jsch - 1.6.5-0jpp_1fc.i386 requires libgcj.so.6 ant-junit - 1.6.5-0jpp_1fc.i386 requires libgcj.so.6 ant-nodeps - 1.6.5-0jpp_1fc.i386 requires libgcj.so.6 ant-swing - 1.6.5-0jpp_1fc.i386 requires libgcj.so.6 ant-trax - 1.6.5-0jpp_1fc.i386 requires libgcj.so.6 apr-devel - 1.2.2-4.i386 requires gcc = 0:4.0.2 cairo-java - 1.0.1-2.i386 requires libgcj.so.6 carol - 1.8.9.3-1jpp_6fc.i386 requires libgcj.so.6 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel = 0:2.6.14-1.1696_FC5 cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5smp cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 eclipse-bugzilla - 1:0.1.1_fc-5.i386 requires libgcj.so.6 eclipse-cdt - 1:3.0.1-1jpp_1fc.i386 requires libgcj.so.6 eclipse-changelog - 1:2.0.1_fc-22.i386 requires libgcj.so.6 eclipse-ecj - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-jdt - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-pde - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-platform - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-pydev - 1:0.9.3_fc-12.i386 requires libgcj.so.6 frysk - 0.0.0.20051116-0.5.i386 requires libgcj.so.6 geronimo-specs - 1.0-0.M2.2jpp_4fc.i386 requires libgcj.so.6 gettext-devel - 0.14.5-2.i386 requires libgcj.so.6 glib-java - 0.2.1-2.i386 requires libgcj.so.6 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel = 0:2.6.14-1.1696_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 gnu-crypto - 2.0.1-1jpp_8fc.i386 requires libgcj.so.6 gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.i386 requires libgcj.so.6 gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.i386 requires libgcj.so.6 howl-logger - 0.1.8-1jpp_3fc.i386 requires libgcj.so.6 hsqldb - 1.80.1-1jpp_4fc.i386 requires libgcj.so.6 jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 jakarta-commons-beanutils - 1.7.0-2jpp_2fc.i386 requires libgcj.so.6 jakarta-commons-collections - 3.1-2jpp_2fc.i386 requires libgcj.so.6 jakarta-commons-digester - 1.6-2jpp_6fc.i386 requires libgcj.so.6 jakarta-commons-el - 1.0-4jpp_2fc.i386 requires libgcj.so.6 jakarta-commons-logging - 1.0.4-2jpp_6fc.i386 requires libgcj.so.6 jakarta-commons-modeler - 1.1-4jpp_2fc.i386 requires libgcj.so.6 java_cup - 1:0.10-0.k.1jpp_5fc.i386 requires libgcj.so.6 javacc - 3.2-1jpp_3fc.i386 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonathan-core - 4.1-1jpp_4fc.i386 requires libgcj.so.6 jonathan-jeremie - 4.2-1jpp_4fc.i386 requires libgcj.so.6 jonathan-rmi - 3.1-5.i386 requires libgcj.so.6 joram - 4.1.5-1jpp_6fc.i386 requires libgcj.so.6 jotm - 2.0.5-1jpp_3fc.i386 requires libgcj.so.6 jsch - 0.1.18-1jpp_2fc.i386 requires libgcj.so.6 libgconf-java - 2.12.1-1.i386 requires libgcj.so.6 libglade-java - 2.12.1-2.i386 requires libgcj.so.6 libgnome-java - 2.12.1-2.i386 requires libgcj.so.6 libgtk-java - 2.8.1-1.i386 requires libgcj.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.i386 requires libgcjawt.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 libvte-java - 0.11.11-6.i386 requires libgcj.so.6 lucene - 1.4.3-1jpp_7fc.i386 requires libgcj.so.6 lucene-demo - 1.4.3-1jpp_7fc.i386 requires libgcj.so.6 monolog - 1.8.6-1jpp_5fc.i386 requires libgcj.so.6 mx4j - 1:3.0.1-1jpp_5fc.i386 requires libgcj.so.6 nanoxml - 2.2.3-3jpp_3fc.i386 requires libgcj.so.6 nanoxml-lite - 2.2.3-3jpp_3fc.i386 requires libgcj.so.6 oldkilim - 1.1.3-2jpp_3fc.i386 requires libgcj.so.6 openoffice.org-core - 1:2.0.1-143.1.2.i386 requires libgcjawt.so.6 openoffice.org-core - 1:2.0.1-143.1.2.i386 requires libgcj.so.6 p6spy - 1.3-2jpp_3fc.i386 requires libgcj.so.6 regexp - 1.3-2jpp_3fc.i386 requires libgcj.so.6 struts - 1.2.4-2jpp_3fc.i386 requires libgcj.so.6 struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.i386 requires libgcj.so.6 systemtap - 0.5-2.i386 requires libdw.so.1(ELFUTILS_0.116) tomcat5 - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 tomcat5-admin-webapps - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 tomcat5-jasper - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 tomcat5-webapps - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 xalan-j2 - 2.6.0-3jpp_4fc.i386 requires libgcj.so.6 xalan-j2-demo - 2.6.0-3jpp_4fc.i386 requires libgcj.so.6 xalan-j2-xsltc - 2.6.0-3jpp_4fc.i386 requires libgcj.so.6 xerces-j2 - 2.6.2-5jpp_2fc.i386 requires libgcj.so.6 xerces-j2-demo - 2.6.2-5jpp_2fc.i386 requires libgcj.so.6 xml-commons-apis - 1.0-0.b2.7jpp_3fc.i386 requires libgcj.so.6 xml-commons-which - 1.0-0.b2.7jpp_3fc.i386 requires libgcj.so.6 Broken deps for ia64 ---------------------------------------------------------- ant - 1.6.5-0jpp_1fc.ia64 requires libgcj.so.6()(64bit) ant-antlr - 1.6.5-0jpp_1fc.ia64 requires libgcj.so.6()(64bit) ant-apache-bcel - 1.6.5-0jpp_1fc.ia64 requires libgcj.so.6()(64bit) ant-apache-bsf - 1.6.5-0jpp_1fc.ia64 requires libgcj.so.6()(64bit) ant-apache-log4j - 1.6.5-0jpp_1fc.ia64 requires libgcj.so.6()(64bit) ant-apache-oro - 1.6.5-0jpp_1fc.ia64 requires libgcj.so.6()(64bit) ant-apache-regexp - 1.6.5-0jpp_1fc.ia64 requires libgcj.so.6()(64bit) ant-apache-resolver - 1.6.5-0jpp_1fc.ia64 requires libgcj.so.6()(64bit) ant-commons-logging - 1.6.5-0jpp_1fc.ia64 requires libgcj.so.6()(64bit) ant-javamail - 1.6.5-0jpp_1fc.ia64 requires libgcj.so.6()(64bit) ant-jdepend - 1.6.5-0jpp_1fc.ia64 requires libgcj.so.6()(64bit) ant-jsch - 1.6.5-0jpp_1fc.ia64 requires libgcj.so.6()(64bit) ant-junit - 1.6.5-0jpp_1fc.ia64 requires libgcj.so.6()(64bit) ant-nodeps - 1.6.5-0jpp_1fc.ia64 requires libgcj.so.6()(64bit) ant-swing - 1.6.5-0jpp_1fc.ia64 requires libgcj.so.6()(64bit) ant-trax - 1.6.5-0jpp_1fc.ia64 requires libgcj.so.6()(64bit) apr-devel - 1.2.2-4.ia64 requires gcc = 0:4.0.2 cairo-java - 1.0.1-2.ia64 requires libgcj.so.6()(64bit) carol - 1.8.9.3-1jpp_6fc.ia64 requires libgcj.so.6()(64bit) geronimo-specs - 1.0-0.M2.2jpp_4fc.ia64 requires libgcj.so.6()(64bit) gettext-devel - 0.14.5-2.ia64 requires libgcj.so.6()(64bit) glib-java - 0.2.1-2.ia64 requires libgcj.so.6()(64bit) gnu-crypto - 2.0.1-1jpp_8fc.ia64 requires libgcj.so.6()(64bit) gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.ia64 requires libgcj.so.6()(64bit) gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.ia64 requires libgcj.so.6()(64bit) howl-logger - 0.1.8-1jpp_3fc.ia64 requires libgcj.so.6()(64bit) hsqldb - 1.80.1-1jpp_4fc.ia64 requires libgcj.so.6()(64bit) jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) jakarta-commons-beanutils - 1.7.0-2jpp_2fc.ia64 requires libgcj.so.6()(64bit) jakarta-commons-collections - 3.1-2jpp_2fc.ia64 requires libgcj.so.6()(64bit) jakarta-commons-digester - 1.6-2jpp_6fc.ia64 requires libgcj.so.6()(64bit) jakarta-commons-el - 1.0-4jpp_2fc.ia64 requires libgcj.so.6()(64bit) jakarta-commons-logging - 1.0.4-2jpp_6fc.ia64 requires libgcj.so.6()(64bit) jakarta-commons-modeler - 1.1-4jpp_2fc.ia64 requires libgcj.so.6()(64bit) java_cup - 1:0.10-0.k.1jpp_5fc.ia64 requires libgcj.so.6()(64bit) javacc - 3.2-1jpp_3fc.ia64 requires libgcj.so.6()(64bit) jonathan-core - 4.1-1jpp_4fc.ia64 requires libgcj.so.6()(64bit) jonathan-jeremie - 4.2-1jpp_4fc.ia64 requires libgcj.so.6()(64bit) jonathan-rmi - 3.1-5.ia64 requires libgcj.so.6()(64bit) joram - 4.1.5-1jpp_6fc.ia64 requires libgcj.so.6()(64bit) jotm - 2.0.5-1jpp_3fc.ia64 requires libgcj.so.6()(64bit) jsch - 0.1.18-1jpp_2fc.ia64 requires libgcj.so.6()(64bit) libgconf-java - 2.12.1-1.ia64 requires libgcj.so.6()(64bit) libglade-java - 2.12.1-2.ia64 requires libgcj.so.6()(64bit) libgnome-java - 2.12.1-2.ia64 requires libgcj.so.6()(64bit) libgtk-java - 2.8.1-1.ia64 requires libgcj.so.6()(64bit) libsetrans - 0.1.11-1.ia64 requires libc.so.6(GLIBC_2.3.4) libsetrans - 0.1.11-1.ia64 requires libc.so.6(GLIBC_2.4) libsetrans - 0.1.11-1.ia64 requires libc.so.6(GLIBC_2.1) libsetrans - 0.1.11-1.ia64 requires libc.so.6(GLIBC_2.0) libsetrans - 0.1.11-1.ia64 requires libdl.so.2 libsetrans - 0.1.11-1.ia64 requires libc.so.6(GLIBC_2.1.3) libsetrans - 0.1.11-1.ia64 requires libc.so.6(GLIBC_2.3) libsetrans - 0.1.11-1.ia64 requires libc.so.6 libsetrans - 0.1.11-1.ia64 requires libselinux.so.1 libvte-java - 0.11.11-6.ia64 requires libgcj.so.6()(64bit) lucene - 1.4.3-1jpp_7fc.ia64 requires libgcj.so.6()(64bit) lucene-demo - 1.4.3-1jpp_7fc.ia64 requires libgcj.so.6()(64bit) monolog - 1.8.6-1jpp_5fc.ia64 requires libgcj.so.6()(64bit) mx4j - 1:3.0.1-1jpp_5fc.ia64 requires libgcj.so.6()(64bit) nanoxml - 2.2.3-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) nanoxml-lite - 2.2.3-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) oldkilim - 1.1.3-2jpp_3fc.ia64 requires libgcj.so.6()(64bit) p6spy - 1.3-2jpp_3fc.ia64 requires libgcj.so.6()(64bit) regexp - 1.3-2jpp_3fc.ia64 requires libgcj.so.6()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs struts - 1.2.4-2jpp_3fc.ia64 requires libgcj.so.6()(64bit) struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.ia64 requires libgcj.so.6()(64bit) systemtap - 0.5-2.ia64 requires libdw.so.1(ELFUTILS_0.116)(64bit) tomcat5 - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) tomcat5-admin-webapps - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) tomcat5-jasper - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) tomcat5-webapps - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) xalan-j2 - 2.6.0-3jpp_4fc.ia64 requires libgcj.so.6()(64bit) xalan-j2-demo - 2.6.0-3jpp_4fc.ia64 requires libgcj.so.6()(64bit) xalan-j2-xsltc - 2.6.0-3jpp_4fc.ia64 requires libgcj.so.6()(64bit) xerces-j2 - 2.6.2-5jpp_2fc.ia64 requires libgcj.so.6()(64bit) xerces-j2-demo - 2.6.2-5jpp_2fc.ia64 requires libgcj.so.6()(64bit) xml-commons-apis - 1.0-0.b2.7jpp_3fc.ia64 requires libgcj.so.6()(64bit) xml-commons-which - 1.0-0.b2.7jpp_3fc.ia64 requires libgcj.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- ant - 1.6.5-0jpp_1fc.ppc requires libgcj.so.6 ant-antlr - 1.6.5-0jpp_1fc.ppc requires libgcj.so.6 ant-apache-bcel - 1.6.5-0jpp_1fc.ppc requires libgcj.so.6 ant-apache-bsf - 1.6.5-0jpp_1fc.ppc requires libgcj.so.6 ant-apache-log4j - 1.6.5-0jpp_1fc.ppc requires libgcj.so.6 ant-apache-oro - 1.6.5-0jpp_1fc.ppc requires libgcj.so.6 ant-apache-regexp - 1.6.5-0jpp_1fc.ppc requires libgcj.so.6 ant-apache-resolver - 1.6.5-0jpp_1fc.ppc requires libgcj.so.6 ant-commons-logging - 1.6.5-0jpp_1fc.ppc requires libgcj.so.6 ant-javamail - 1.6.5-0jpp_1fc.ppc requires libgcj.so.6 ant-jdepend - 1.6.5-0jpp_1fc.ppc requires libgcj.so.6 ant-jsch - 1.6.5-0jpp_1fc.ppc requires libgcj.so.6 ant-junit - 1.6.5-0jpp_1fc.ppc requires libgcj.so.6 ant-nodeps - 1.6.5-0jpp_1fc.ppc requires libgcj.so.6 ant-swing - 1.6.5-0jpp_1fc.ppc requires libgcj.so.6 ant-trax - 1.6.5-0jpp_1fc.ppc requires libgcj.so.6 apr-devel - 1.2.2-4.ppc requires gcc = 0:4.0.2 cairo-java - 1.0.1-2.ppc requires libgcj.so.6 carol - 1.8.9.3-1jpp_6fc.ppc requires libgcj.so.6 cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 eclipse-bugzilla - 1:0.1.1_fc-5.ppc requires libgcj.so.6 eclipse-cdt - 1:3.0.1-1jpp_1fc.ppc requires libgcj.so.6 eclipse-changelog - 1:2.0.1_fc-22.ppc requires libgcj.so.6 eclipse-ecj - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-jdt - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-pde - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-platform - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-pydev - 1:0.9.3_fc-12.ppc requires libgcj.so.6 geronimo-specs - 1.0-0.M2.2jpp_4fc.ppc requires libgcj.so.6 gettext-devel - 0.14.5-2.ppc requires libgcj.so.6 glib-java - 0.2.1-2.ppc requires libgcj.so.6 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 gnu-crypto - 2.0.1-1jpp_8fc.ppc requires libgcj.so.6 gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.ppc requires libgcj.so.6 gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.ppc requires libgcj.so.6 howl-logger - 0.1.8-1jpp_3fc.ppc requires libgcj.so.6 hsqldb - 1.80.1-1jpp_4fc.ppc requires libgcj.so.6 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 jakarta-commons-beanutils - 1.7.0-2jpp_2fc.ppc requires libgcj.so.6 jakarta-commons-collections - 3.1-2jpp_2fc.ppc requires libgcj.so.6 jakarta-commons-digester - 1.6-2jpp_6fc.ppc requires libgcj.so.6 jakarta-commons-el - 1.0-4jpp_2fc.ppc requires libgcj.so.6 jakarta-commons-logging - 1.0.4-2jpp_6fc.ppc requires libgcj.so.6 jakarta-commons-modeler - 1.1-4jpp_2fc.ppc requires libgcj.so.6 java_cup - 1:0.10-0.k.1jpp_5fc.ppc requires libgcj.so.6 javacc - 3.2-1jpp_3fc.ppc requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonathan-core - 4.1-1jpp_4fc.ppc requires libgcj.so.6 jonathan-jeremie - 4.2-1jpp_4fc.ppc requires libgcj.so.6 jonathan-rmi - 3.1-5.ppc requires libgcj.so.6 joram - 4.1.5-1jpp_6fc.ppc requires libgcj.so.6 jotm - 2.0.5-1jpp_3fc.ppc requires libgcj.so.6 jsch - 0.1.18-1jpp_2fc.ppc requires libgcj.so.6 libgconf-java - 2.12.1-1.ppc requires libgcj.so.6 libglade-java - 2.12.1-2.ppc requires libgcj.so.6 libgnome-java - 2.12.1-2.ppc requires libgcj.so.6 libgtk-java - 2.8.1-1.ppc requires libgcj.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.ppc requires libgcjawt.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 libvte-java - 0.11.11-6.ppc requires libgcj.so.6 lucene - 1.4.3-1jpp_7fc.ppc requires libgcj.so.6 lucene-demo - 1.4.3-1jpp_7fc.ppc requires libgcj.so.6 monolog - 1.8.6-1jpp_5fc.ppc requires libgcj.so.6 mx4j - 1:3.0.1-1jpp_5fc.ppc requires libgcj.so.6 nanoxml - 2.2.3-3jpp_3fc.ppc requires libgcj.so.6 nanoxml-lite - 2.2.3-3jpp_3fc.ppc requires libgcj.so.6 oldkilim - 1.1.3-2jpp_3fc.ppc requires libgcj.so.6 openoffice.org-core - 1:2.0.1-143.1.2.ppc requires libgcjawt.so.6 openoffice.org-core - 1:2.0.1-143.1.2.ppc requires libgcj.so.6 p6spy - 1.3-2jpp_3fc.ppc requires libgcj.so.6 regexp - 1.3-2jpp_3fc.ppc requires libgcj.so.6 struts - 1.2.4-2jpp_3fc.ppc requires libgcj.so.6 struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.ppc requires libgcj.so.6 systemtap - 0.5-2.ppc requires libdw.so.1(ELFUTILS_0.116) tomcat5 - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 tomcat5-admin-webapps - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 tomcat5-jasper - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 tomcat5-webapps - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 xalan-j2 - 2.6.0-3jpp_4fc.ppc requires libgcj.so.6 xalan-j2-demo - 2.6.0-3jpp_4fc.ppc requires libgcj.so.6 xalan-j2-xsltc - 2.6.0-3jpp_4fc.ppc requires libgcj.so.6 xerces-j2 - 2.6.2-5jpp_2fc.ppc requires libgcj.so.6 xerces-j2-demo - 2.6.2-5jpp_2fc.ppc requires libgcj.so.6 xml-commons-apis - 1.0-0.b2.7jpp_3fc.ppc requires libgcj.so.6 xml-commons-which - 1.0-0.b2.7jpp_3fc.ppc requires libgcj.so.6 Broken deps for ppc64 ---------------------------------------------------------- ant - 1.6.5-0jpp_1fc.ppc64 requires libgcj.so.6()(64bit) ant-antlr - 1.6.5-0jpp_1fc.ppc64 requires libgcj.so.6()(64bit) ant-apache-bcel - 1.6.5-0jpp_1fc.ppc64 requires libgcj.so.6()(64bit) ant-apache-bsf - 1.6.5-0jpp_1fc.ppc64 requires libgcj.so.6()(64bit) ant-apache-log4j - 1.6.5-0jpp_1fc.ppc64 requires libgcj.so.6()(64bit) ant-apache-oro - 1.6.5-0jpp_1fc.ppc64 requires libgcj.so.6()(64bit) ant-apache-regexp - 1.6.5-0jpp_1fc.ppc64 requires libgcj.so.6()(64bit) ant-apache-resolver - 1.6.5-0jpp_1fc.ppc64 requires libgcj.so.6()(64bit) ant-commons-logging - 1.6.5-0jpp_1fc.ppc64 requires libgcj.so.6()(64bit) ant-javamail - 1.6.5-0jpp_1fc.ppc64 requires libgcj.so.6()(64bit) ant-jdepend - 1.6.5-0jpp_1fc.ppc64 requires libgcj.so.6()(64bit) ant-jsch - 1.6.5-0jpp_1fc.ppc64 requires libgcj.so.6()(64bit) ant-junit - 1.6.5-0jpp_1fc.ppc64 requires libgcj.so.6()(64bit) ant-nodeps - 1.6.5-0jpp_1fc.ppc64 requires libgcj.so.6()(64bit) ant-swing - 1.6.5-0jpp_1fc.ppc64 requires libgcj.so.6()(64bit) ant-trax - 1.6.5-0jpp_1fc.ppc64 requires libgcj.so.6()(64bit) apr-devel - 1.2.2-4.ppc64 requires gcc = 0:4.0.2 cairo-java - 1.0.1-2.ppc64 requires libgcj.so.6()(64bit) carol - 1.8.9.3-1jpp_6fc.ppc64 requires libgcj.so.6()(64bit) cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi geronimo-specs - 1.0-0.M2.2jpp_4fc.ppc64 requires libgcj.so.6()(64bit) gettext-devel - 0.14.5-2.ppc64 requires libgcj.so.6()(64bit) glib-java - 0.2.1-2.ppc64 requires libgcj.so.6()(64bit) gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 gnu-crypto - 2.0.1-1jpp_8fc.ppc64 requires libgcj.so.6()(64bit) gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.ppc64 requires libgcj.so.6()(64bit) gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.ppc64 requires libgcj.so.6()(64bit) howl-logger - 0.1.8-1jpp_3fc.ppc64 requires libgcj.so.6()(64bit) hsqldb - 1.80.1-1jpp_4fc.ppc64 requires libgcj.so.6()(64bit) jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) jakarta-commons-beanutils - 1.7.0-2jpp_2fc.ppc64 requires libgcj.so.6()(64bit) jakarta-commons-collections - 3.1-2jpp_2fc.ppc64 requires libgcj.so.6()(64bit) jakarta-commons-digester - 1.6-2jpp_6fc.ppc64 requires libgcj.so.6()(64bit) jakarta-commons-el - 1.0-4jpp_2fc.ppc64 requires libgcj.so.6()(64bit) jakarta-commons-logging - 1.0.4-2jpp_6fc.ppc64 requires libgcj.so.6()(64bit) jakarta-commons-modeler - 1.1-4jpp_2fc.ppc64 requires libgcj.so.6()(64bit) java_cup - 1:0.10-0.k.1jpp_5fc.ppc64 requires libgcj.so.6()(64bit) javacc - 3.2-1jpp_3fc.ppc64 requires libgcj.so.6()(64bit) jonathan-core - 4.1-1jpp_4fc.ppc64 requires libgcj.so.6()(64bit) jonathan-jeremie - 4.2-1jpp_4fc.ppc64 requires libgcj.so.6()(64bit) jonathan-rmi - 3.1-5.ppc64 requires libgcj.so.6()(64bit) joram - 4.1.5-1jpp_6fc.ppc64 requires libgcj.so.6()(64bit) jotm - 2.0.5-1jpp_3fc.ppc64 requires libgcj.so.6()(64bit) jsch - 0.1.18-1jpp_2fc.ppc64 requires libgcj.so.6()(64bit) libgconf-java - 2.12.1-1.ppc64 requires libgcj.so.6()(64bit) libglade-java - 2.12.1-2.ppc64 requires libgcj.so.6()(64bit) libgnome-java - 2.12.1-2.ppc64 requires libgcj.so.6()(64bit) libgtk-java - 2.8.1-1.ppc64 requires libgcj.so.6()(64bit) libsetrans - 0.1.11-1.ppc64 requires libc.so.6(GLIBC_2.3.4) libsetrans - 0.1.11-1.ppc64 requires libc.so.6(GLIBC_2.4) libsetrans - 0.1.11-1.ppc64 requires libc.so.6(GLIBC_2.1) libsetrans - 0.1.11-1.ppc64 requires libc.so.6(GLIBC_2.0) libsetrans - 0.1.11-1.ppc64 requires libdl.so.2 libsetrans - 0.1.11-1.ppc64 requires libc.so.6(GLIBC_2.1.3) libsetrans - 0.1.11-1.ppc64 requires libc.so.6(GLIBC_2.3) libsetrans - 0.1.11-1.ppc64 requires libc.so.6 libsetrans - 0.1.11-1.ppc64 requires libselinux.so.1 libvte-java - 0.11.11-6.ppc64 requires libgcj.so.6()(64bit) lucene - 1.4.3-1jpp_7fc.ppc64 requires libgcj.so.6()(64bit) lucene-demo - 1.4.3-1jpp_7fc.ppc64 requires libgcj.so.6()(64bit) monolog - 1.8.6-1jpp_5fc.ppc64 requires libgcj.so.6()(64bit) mx4j - 1:3.0.1-1jpp_5fc.ppc64 requires libgcj.so.6()(64bit) nanoxml - 2.2.3-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) nanoxml-lite - 2.2.3-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) oldkilim - 1.1.3-2jpp_3fc.ppc64 requires libgcj.so.6()(64bit) p6spy - 1.3-2jpp_3fc.ppc64 requires libgcj.so.6()(64bit) regexp - 1.3-2jpp_3fc.ppc64 requires libgcj.so.6()(64bit) struts - 1.2.4-2jpp_3fc.ppc64 requires libgcj.so.6()(64bit) struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.ppc64 requires libgcj.so.6()(64bit) tomcat5 - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) tomcat5-admin-webapps - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) tomcat5-jasper - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) tomcat5-webapps - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) xalan-j2 - 2.6.0-3jpp_4fc.ppc64 requires libgcj.so.6()(64bit) xalan-j2-demo - 2.6.0-3jpp_4fc.ppc64 requires libgcj.so.6()(64bit) xalan-j2-xsltc - 2.6.0-3jpp_4fc.ppc64 requires libgcj.so.6()(64bit) xerces-j2 - 2.6.2-5jpp_2fc.ppc64 requires libgcj.so.6()(64bit) xerces-j2-demo - 2.6.2-5jpp_2fc.ppc64 requires libgcj.so.6()(64bit) xml-commons-apis - 1.0-0.b2.7jpp_3fc.ppc64 requires libgcj.so.6()(64bit) xml-commons-which - 1.0-0.b2.7jpp_3fc.ppc64 requires libgcj.so.6()(64bit) Broken deps for s390 ---------------------------------------------------------- ant - 1.6.5-0jpp_1fc.s390 requires libgcj.so.6 ant-antlr - 1.6.5-0jpp_1fc.s390 requires libgcj.so.6 ant-apache-bcel - 1.6.5-0jpp_1fc.s390 requires libgcj.so.6 ant-apache-bsf - 1.6.5-0jpp_1fc.s390 requires libgcj.so.6 ant-apache-log4j - 1.6.5-0jpp_1fc.s390 requires libgcj.so.6 ant-apache-oro - 1.6.5-0jpp_1fc.s390 requires libgcj.so.6 ant-apache-regexp - 1.6.5-0jpp_1fc.s390 requires libgcj.so.6 ant-apache-resolver - 1.6.5-0jpp_1fc.s390 requires libgcj.so.6 ant-commons-logging - 1.6.5-0jpp_1fc.s390 requires libgcj.so.6 ant-javamail - 1.6.5-0jpp_1fc.s390 requires libgcj.so.6 ant-jdepend - 1.6.5-0jpp_1fc.s390 requires libgcj.so.6 ant-jsch - 1.6.5-0jpp_1fc.s390 requires libgcj.so.6 ant-junit - 1.6.5-0jpp_1fc.s390 requires libgcj.so.6 ant-nodeps - 1.6.5-0jpp_1fc.s390 requires libgcj.so.6 ant-swing - 1.6.5-0jpp_1fc.s390 requires libgcj.so.6 ant-trax - 1.6.5-0jpp_1fc.s390 requires libgcj.so.6 apr-devel - 1.2.2-4.s390 requires gcc = 0:4.0.2 cairo-java - 1.0.1-2.s390 requires libgcj.so.6 carol - 1.8.9.3-1jpp_6fc.s390 requires libgcj.so.6 geronimo-specs - 1.0-0.M2.2jpp_4fc.s390 requires libgcj.so.6 gettext-devel - 0.14.5-2.s390 requires libgcj.so.6 glib-java - 0.2.1-2.s390 requires libgcj.so.6 gnu-crypto - 2.0.1-1jpp_8fc.s390 requires libgcj.so.6 gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.s390 requires libgcj.so.6 gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.s390 requires libgcj.so.6 howl-logger - 0.1.8-1jpp_3fc.s390 requires libgcj.so.6 hsqldb - 1.80.1-1jpp_4fc.s390 requires libgcj.so.6 jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jakarta-commons-beanutils - 1.7.0-2jpp_2fc.s390 requires libgcj.so.6 jakarta-commons-collections - 3.1-2jpp_2fc.s390 requires libgcj.so.6 jakarta-commons-digester - 1.6-2jpp_6fc.s390 requires libgcj.so.6 jakarta-commons-el - 1.0-4jpp_2fc.s390 requires libgcj.so.6 jakarta-commons-logging - 1.0.4-2jpp_6fc.s390 requires libgcj.so.6 jakarta-commons-modeler - 1.1-4jpp_2fc.s390 requires libgcj.so.6 java_cup - 1:0.10-0.k.1jpp_5fc.s390 requires libgcj.so.6 javacc - 3.2-1jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonathan-core - 4.1-1jpp_4fc.s390 requires libgcj.so.6 jonathan-jeremie - 4.2-1jpp_4fc.s390 requires libgcj.so.6 jonathan-rmi - 3.1-5.s390 requires libgcj.so.6 joram - 4.1.5-1jpp_6fc.s390 requires libgcj.so.6 jotm - 2.0.5-1jpp_3fc.s390 requires libgcj.so.6 jsch - 0.1.18-1jpp_2fc.s390 requires libgcj.so.6 libgconf-java - 2.12.1-1.s390 requires libgcj.so.6 libglade-java - 2.12.1-2.s390 requires libgcj.so.6 libgnome-java - 2.12.1-2.s390 requires libgcj.so.6 libgtk-java - 2.8.1-1.s390 requires libgcj.so.6 libvte-java - 0.11.11-6.s390 requires libgcj.so.6 lucene - 1.4.3-1jpp_7fc.s390 requires libgcj.so.6 lucene-demo - 1.4.3-1jpp_7fc.s390 requires libgcj.so.6 monolog - 1.8.6-1jpp_5fc.s390 requires libgcj.so.6 mx4j - 1:3.0.1-1jpp_5fc.s390 requires libgcj.so.6 nanoxml - 2.2.3-3jpp_3fc.s390 requires libgcj.so.6 nanoxml-lite - 2.2.3-3jpp_3fc.s390 requires libgcj.so.6 oldkilim - 1.1.3-2jpp_3fc.s390 requires libgcj.so.6 p6spy - 1.3-2jpp_3fc.s390 requires libgcj.so.6 regexp - 1.3-2jpp_3fc.s390 requires libgcj.so.6 rhythmbox - 0.9.1-1.s390 requires libdbus-1.so.1 rhythmbox - 0.9.1-1.s390 requires libdbus-glib-1.so.1 struts - 1.2.4-2jpp_3fc.s390 requires libgcj.so.6 struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.s390 requires libgcj.so.6 tomcat5 - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 tomcat5-admin-webapps - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 tomcat5-jasper - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 tomcat5-webapps - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 xalan-j2 - 2.6.0-3jpp_4fc.s390 requires libgcj.so.6 xalan-j2-demo - 2.6.0-3jpp_4fc.s390 requires libgcj.so.6 xalan-j2-xsltc - 2.6.0-3jpp_4fc.s390 requires libgcj.so.6 xerces-j2 - 2.6.2-5jpp_2fc.s390 requires libgcj.so.6 xerces-j2-demo - 2.6.2-5jpp_2fc.s390 requires libgcj.so.6 xml-commons-apis - 1.0-0.b2.7jpp_3fc.s390 requires libgcj.so.6 xml-commons-which - 1.0-0.b2.7jpp_3fc.s390 requires libgcj.so.6 Broken deps for s390x ---------------------------------------------------------- ant - 1.6.5-0jpp_1fc.s390x requires libgcj.so.6()(64bit) ant-antlr - 1.6.5-0jpp_1fc.s390x requires libgcj.so.6()(64bit) ant-apache-bcel - 1.6.5-0jpp_1fc.s390x requires libgcj.so.6()(64bit) ant-apache-bsf - 1.6.5-0jpp_1fc.s390x requires libgcj.so.6()(64bit) ant-apache-log4j - 1.6.5-0jpp_1fc.s390x requires libgcj.so.6()(64bit) ant-apache-oro - 1.6.5-0jpp_1fc.s390x requires libgcj.so.6()(64bit) ant-apache-regexp - 1.6.5-0jpp_1fc.s390x requires libgcj.so.6()(64bit) ant-apache-resolver - 1.6.5-0jpp_1fc.s390x requires libgcj.so.6()(64bit) ant-commons-logging - 1.6.5-0jpp_1fc.s390x requires libgcj.so.6()(64bit) ant-javamail - 1.6.5-0jpp_1fc.s390x requires libgcj.so.6()(64bit) ant-jdepend - 1.6.5-0jpp_1fc.s390x requires libgcj.so.6()(64bit) ant-jsch - 1.6.5-0jpp_1fc.s390x requires libgcj.so.6()(64bit) ant-junit - 1.6.5-0jpp_1fc.s390x requires libgcj.so.6()(64bit) ant-nodeps - 1.6.5-0jpp_1fc.s390x requires libgcj.so.6()(64bit) ant-swing - 1.6.5-0jpp_1fc.s390x requires libgcj.so.6()(64bit) ant-trax - 1.6.5-0jpp_1fc.s390x requires libgcj.so.6()(64bit) apr-devel - 1.2.2-4.s390x requires gcc = 0:4.0.2 cairo-java - 1.0.0-10.s390x requires libgcj.so.6()(64bit) carol - 1.8.9.3-1jpp_6fc.s390x requires libgcj.so.6()(64bit) geronimo-specs - 1.0-0.M2.2jpp_4fc.s390x requires libgcj.so.6()(64bit) gettext-devel - 0.14.5-2.s390x requires libgcj.so.6()(64bit) glib-java - 0.2.0-6.s390x requires libgcj.so.6()(64bit) gnu-crypto - 2.0.1-1jpp_8fc.s390x requires libgcj.so.6()(64bit) gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.s390x requires libgcj.so.6()(64bit) gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.s390x requires libgcj.so.6()(64bit) howl-logger - 0.1.8-1jpp_3fc.s390x requires libgcj.so.6()(64bit) hsqldb - 1.80.1-1jpp_4fc.s390x requires libgcj.so.6()(64bit) jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) jakarta-commons-beanutils - 1.7.0-2jpp_2fc.s390x requires libgcj.so.6()(64bit) jakarta-commons-collections - 3.1-2jpp_2fc.s390x requires libgcj.so.6()(64bit) jakarta-commons-digester - 1.6-2jpp_6fc.s390x requires libgcj.so.6()(64bit) jakarta-commons-el - 1.0-4jpp_2fc.s390x requires libgcj.so.6()(64bit) jakarta-commons-logging - 1.0.4-2jpp_6fc.s390x requires libgcj.so.6()(64bit) jakarta-commons-modeler - 1.1-4jpp_2fc.s390x requires libgcj.so.6()(64bit) java_cup - 1:0.10-0.k.1jpp_5fc.s390x requires libgcj.so.6()(64bit) javacc - 3.2-1jpp_3fc.s390x requires libgcj.so.6()(64bit) jonathan-core - 4.1-1jpp_4fc.s390x requires libgcj.so.6()(64bit) jonathan-jeremie - 4.2-1jpp_4fc.s390x requires libgcj.so.6()(64bit) jonathan-rmi - 3.1-5.s390x requires libgcj.so.6()(64bit) joram - 4.1.5-1jpp_6fc.s390x requires libgcj.so.6()(64bit) jotm - 2.0.5-1jpp_3fc.s390x requires libgcj.so.6()(64bit) jsch - 0.1.18-1jpp_2fc.s390x requires libgcj.so.6()(64bit) libgconf-java - 2.12.0-2.s390x requires libgcj.so.6()(64bit) libglade-java - 2.12.0-5.s390x requires libgcj.so.6()(64bit) libgnome-java - 2.12.0-2.s390x requires libgcj.so.6()(64bit) libgtk-java - 2.8.0-7.s390x requires libgcj.so.6()(64bit) libvte-java - 0.11.11-6.s390x requires libgcj.so.6()(64bit) lucene - 1.4.3-1jpp_7fc.s390x requires libgcj.so.6()(64bit) lucene-demo - 1.4.3-1jpp_7fc.s390x requires libgcj.so.6()(64bit) monolog - 1.8.6-1jpp_5fc.s390x requires libgcj.so.6()(64bit) mx4j - 1:3.0.1-1jpp_5fc.s390x requires libgcj.so.6()(64bit) nanoxml - 2.2.3-3jpp_3fc.s390x requires libgcj.so.6()(64bit) nanoxml-lite - 2.2.3-3jpp_3fc.s390x requires libgcj.so.6()(64bit) oldkilim - 1.1.3-2jpp_3fc.s390x requires libgcj.so.6()(64bit) p6spy - 1.3-2jpp_3fc.s390x requires libgcj.so.6()(64bit) regexp - 1.3-2jpp_3fc.s390x requires libgcj.so.6()(64bit) rhythmbox - 0.9.1-1.s390x requires libdbus-1.so.1()(64bit) rhythmbox - 0.9.1-1.s390x requires libdbus-glib-1.so.1()(64bit) struts - 1.2.4-2jpp_3fc.s390x requires libgcj.so.6()(64bit) struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.s390x requires libgcj.so.6()(64bit) tomcat5 - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) tomcat5-admin-webapps - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) tomcat5-jasper - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) tomcat5-webapps - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) xalan-j2 - 2.6.0-3jpp_4fc.s390x requires libgcj.so.6()(64bit) xalan-j2-demo - 2.6.0-3jpp_4fc.s390x requires libgcj.so.6()(64bit) xalan-j2-xsltc - 2.6.0-3jpp_4fc.s390x requires libgcj.so.6()(64bit) xerces-j2 - 2.6.2-5jpp_2fc.s390x requires libgcj.so.6()(64bit) xerces-j2-demo - 2.6.2-5jpp_2fc.s390x requires libgcj.so.6()(64bit) xml-commons-apis - 1.0-0.b2.7jpp_3fc.s390x requires libgcj.so.6()(64bit) xml-commons-which - 1.0-0.b2.7jpp_3fc.s390x requires libgcj.so.6()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 ant - 1.6.5-0jpp_1fc.x86_64 requires libgcj.so.6()(64bit) ant-antlr - 1.6.5-0jpp_1fc.x86_64 requires libgcj.so.6()(64bit) ant-apache-bcel - 1.6.5-0jpp_1fc.x86_64 requires libgcj.so.6()(64bit) ant-apache-bsf - 1.6.5-0jpp_1fc.x86_64 requires libgcj.so.6()(64bit) ant-apache-log4j - 1.6.5-0jpp_1fc.x86_64 requires libgcj.so.6()(64bit) ant-apache-oro - 1.6.5-0jpp_1fc.x86_64 requires libgcj.so.6()(64bit) ant-apache-regexp - 1.6.5-0jpp_1fc.x86_64 requires libgcj.so.6()(64bit) ant-apache-resolver - 1.6.5-0jpp_1fc.x86_64 requires libgcj.so.6()(64bit) ant-commons-logging - 1.6.5-0jpp_1fc.x86_64 requires libgcj.so.6()(64bit) ant-javamail - 1.6.5-0jpp_1fc.x86_64 requires libgcj.so.6()(64bit) ant-jdepend - 1.6.5-0jpp_1fc.x86_64 requires libgcj.so.6()(64bit) ant-jsch - 1.6.5-0jpp_1fc.x86_64 requires libgcj.so.6()(64bit) ant-junit - 1.6.5-0jpp_1fc.x86_64 requires libgcj.so.6()(64bit) ant-nodeps - 1.6.5-0jpp_1fc.x86_64 requires libgcj.so.6()(64bit) ant-swing - 1.6.5-0jpp_1fc.x86_64 requires libgcj.so.6()(64bit) ant-trax - 1.6.5-0jpp_1fc.x86_64 requires libgcj.so.6()(64bit) apr-devel - 1.2.2-4.x86_64 requires gcc = 0:4.0.2 cairo-java - 1.0.1-2.x86_64 requires libgcj.so.6()(64bit) carol - 1.8.9.3-1jpp_6fc.x86_64 requires libgcj.so.6()(64bit) cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 eclipse-bugzilla - 1:0.1.1_fc-5.x86_64 requires libgcj.so.6()(64bit) eclipse-cdt - 1:3.0.1-1jpp_1fc.x86_64 requires libgcj.so.6()(64bit) eclipse-changelog - 1:2.0.1_fc-22.x86_64 requires libgcj.so.6()(64bit) eclipse-ecj - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-jdt - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-pde - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-platform - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-pydev - 1:0.9.3_fc-12.x86_64 requires libgcj.so.6()(64bit) geronimo-specs - 1.0-0.M2.2jpp_4fc.x86_64 requires libgcj.so.6()(64bit) gettext-devel - 0.14.5-2.x86_64 requires libgcj.so.6()(64bit) glib-java - 0.2.1-2.x86_64 requires libgcj.so.6()(64bit) gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 gnu-crypto - 2.0.1-1jpp_8fc.x86_64 requires libgcj.so.6()(64bit) gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.x86_64 requires libgcj.so.6()(64bit) gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.x86_64 requires libgcj.so.6()(64bit) howl-logger - 0.1.8-1jpp_3fc.x86_64 requires libgcj.so.6()(64bit) hsqldb - 1.80.1-1jpp_4fc.x86_64 requires libgcj.so.6()(64bit) jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jakarta-commons-beanutils - 1.7.0-2jpp_2fc.x86_64 requires libgcj.so.6()(64bit) jakarta-commons-collections - 3.1-2jpp_2fc.x86_64 requires libgcj.so.6()(64bit) jakarta-commons-digester - 1.6-2jpp_6fc.x86_64 requires libgcj.so.6()(64bit) jakarta-commons-el - 1.0-4jpp_2fc.x86_64 requires libgcj.so.6()(64bit) jakarta-commons-logging - 1.0.4-2jpp_6fc.x86_64 requires libgcj.so.6()(64bit) jakarta-commons-modeler - 1.1-4jpp_2fc.x86_64 requires libgcj.so.6()(64bit) java_cup - 1:0.10-0.k.1jpp_5fc.x86_64 requires libgcj.so.6()(64bit) javacc - 3.2-1jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonathan-core - 4.1-1jpp_4fc.x86_64 requires libgcj.so.6()(64bit) jonathan-jeremie - 4.2-1jpp_4fc.x86_64 requires libgcj.so.6()(64bit) jonathan-rmi - 3.1-5.x86_64 requires libgcj.so.6()(64bit) joram - 4.1.5-1jpp_6fc.x86_64 requires libgcj.so.6()(64bit) jotm - 2.0.5-1jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jsch - 0.1.18-1jpp_2fc.x86_64 requires libgcj.so.6()(64bit) libgconf-java - 2.12.1-1.x86_64 requires libgcj.so.6()(64bit) libglade-java - 2.12.1-2.x86_64 requires libgcj.so.6()(64bit) libgnome-java - 2.12.1-2.x86_64 requires libgcj.so.6()(64bit) libgtk-java - 2.8.1-1.x86_64 requires libgcj.so.6()(64bit) libswt3-gtk2 - 1:3.1.1-1jpp_9fc.x86_64 requires libgcjawt.so.6()(64bit) libswt3-gtk2 - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) libvte-java - 0.11.11-6.x86_64 requires libgcj.so.6()(64bit) lucene - 1.4.3-1jpp_7fc.x86_64 requires libgcj.so.6()(64bit) lucene-demo - 1.4.3-1jpp_7fc.x86_64 requires libgcj.so.6()(64bit) monolog - 1.8.6-1jpp_5fc.x86_64 requires libgcj.so.6()(64bit) mx4j - 1:3.0.1-1jpp_5fc.x86_64 requires libgcj.so.6()(64bit) nanoxml - 2.2.3-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) nanoxml-lite - 2.2.3-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) oldkilim - 1.1.3-2jpp_3fc.x86_64 requires libgcj.so.6()(64bit) openoffice.org-core - 1:2.0.1-143.1.2.i386 requires libgcjawt.so.6 openoffice.org-core - 1:2.0.1-143.1.2.i386 requires libgcj.so.6 p6spy - 1.3-2jpp_3fc.x86_64 requires libgcj.so.6()(64bit) regexp - 1.3-2jpp_3fc.x86_64 requires libgcj.so.6()(64bit) struts - 1.2.4-2jpp_3fc.x86_64 requires libgcj.so.6()(64bit) struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.x86_64 requires libgcj.so.6()(64bit) systemtap - 0.5-2.x86_64 requires libdw.so.1(ELFUTILS_0.116)(64bit) tomcat5 - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) tomcat5-admin-webapps - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) tomcat5-jasper - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) tomcat5-webapps - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) xalan-j2 - 2.6.0-3jpp_4fc.x86_64 requires libgcj.so.6()(64bit) xalan-j2-demo - 2.6.0-3jpp_4fc.x86_64 requires libgcj.so.6()(64bit) xalan-j2-xsltc - 2.6.0-3jpp_4fc.x86_64 requires libgcj.so.6()(64bit) xerces-j2 - 2.6.2-5jpp_2fc.x86_64 requires libgcj.so.6()(64bit) xerces-j2-demo - 2.6.2-5jpp_2fc.x86_64 requires libgcj.so.6()(64bit) xml-commons-apis - 1.0-0.b2.7jpp_3fc.x86_64 requires libgcj.so.6()(64bit) xml-commons-which - 1.0-0.b2.7jpp_3fc.x86_64 requires libgcj.so.6()(64bit) From billcrawford1970 at gmail.com Fri Dec 9 11:31:15 2005 From: billcrawford1970 at gmail.com (Bill Crawford) Date: Fri, 09 Dec 2005 11:31:15 +0000 Subject: yum clean bug In-Reply-To: <1134079174.23944.48.camel@cutter> References: <1134074565.23944.39.camel@cutter> <20051208205137.GA10102@nsk.no-ip.org> <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> <1134078696.1536.1.camel@weasel.turre.laiskiainen.org> <1134079174.23944.48.camel@cutter> Message-ID: <43996B03.5010604@gmail.com> seth vidal wrote: > Seriously? That seems completely backward to me. > > it's like saying rsync --exclude=/some/path should not actually exclude > that path. > > or that a disabled samba share shouldn't ACTUALLY be disabled. > > why on earth do you think yum should do what it's been told NOT to do? > > -sv > > The point is that it's been told not to use the repo. It hasn't been told not to clean the cache. From mukund.miscregisters at gmail.com Fri Dec 9 11:37:43 2005 From: mukund.miscregisters at gmail.com (mukund jampala) Date: Fri, 9 Dec 2005 17:07:43 +0530 Subject: FC4 Hangs when copying more that 40MB to SD card..why? In-Reply-To: <1134124628.19711.104.camel@localhost.localdomain> References: <1134124628.19711.104.camel@localhost.localdomain> Message-ID: Dear David, The same source code worked efficiently for the erlier version of Fedora dists. I was just wanted to know if there is a really a big change either in the kernel or the FC4 which is causing this which I will be required to handle. Also, the sources of these drivers are covered under a NON-GPL liesence and soon will be open once they attain stability. Please do the required help. Regards, Mukund Jampala On 12/9/05, David Woodhouse wrote: > On Fri, 2005-12-09 at 12:43 +0530, mukund jampala wrote: > > Is there any thing new in the FC4 kernel I am required to ahndle in > > the driver? > > Can someone please through some light on this Problem? > > You didn't include a link to the source code of your driver -- how can > we see what you're doing wrong if you didn't show us? > > -- > dwmw2 > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From dwmw2 at infradead.org Fri Dec 9 12:12:30 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 09 Dec 2005 13:12:30 +0100 Subject: FC4 Hangs when copying more that 40MB to SD card..why? In-Reply-To: References: <1134124628.19711.104.camel@localhost.localdomain> Message-ID: <1134130350.19711.106.camel@localhost.localdomain> On Fri, 2005-12-09 at 17:07 +0530, mukund jampala wrote: > Also, the sources of these drivers are covered under a NON-GPL > liesence and soon will be open once they attain stability. There's no need to wait until it's stable before you release it. Unless you show us the source code, we can't help. -- dwmw2 From j.w.r.degoede at hhs.nl Fri Dec 9 12:41:02 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 09 Dec 2005 13:41:02 +0100 Subject: Broken video drivers in new modular X In-Reply-To: <1134125494.14221.12.camel@xpc.home.erwinrol.com> References: <1132564932.8267.20.camel@xpc.home.erwinrol.com> <1134125494.14221.12.camel@xpc.home.erwinrol.com> Message-ID: <43997B5E.405@hhs.nl> Erwin Rol wrote: > The radeon driver is still broken, and only works without acceleration > (anything else causes hard lockup of the whole machine). > Will Xorg 7.0.0R3 be available for rawhide ? > Erm, my radeon 9250 works fine for me. Including DRI ppracer, this is on x86_64 Regards, Hans > - Erwin > > On Mon, 2005-11-21 at 10:22 +0100, Erwin Rol wrote: >> On Mon, 2005-11-21 at 02:44 -0500, Sadda Teh wrote: >>> Hi all, just writing to say that on my Dell Inspiron 8000 laptop >>> (latest BIOS) with ATI Mobility M4 video the modular X vesa and r128 >>> drivers do not work properly. >> My Radeon locks the machine hard, meaning no network, no nothing, only >> can press the reset/power switch. I have seen previous reports here with >> the same problem, but there was talk about that AGP might be the >> problem, but i have a PCIe card (01:00.0 VGA compatible controller: ATI >> Technologies Inc RV370 5B60 [Radeon X300 (PCIE)] ). >> That card worked fine with the old Xorg before the switch to mod-X. >> >>> When X is configured to use the vesa driver it comes up, but the >>> picture is distorted (looks like 2 vertical desktops overlapping one >>> another at various points, also colors are messed up). >> When i use the vesa driver i see things like that too. The icons of >> applications have the wrong colors (looks like R and G and B are >> switched) and they are also at the wrong place (shifted 20 pixels or >> so). >> >> I am now running with the fbdev driver on top of the radeonfb this works >> but is of course not optimal. >> >>> As for trying to use the r128 driver, X cannot even load when >>> configured this way, it fails with an error along the lines of the >>> r128_drv.so could not be opened. Has anyone else seen issues like this >>> with the new modular X packages? Should I file bugs for these in >>> x.org's bugzilla? Thanks. >> Well if it are really the same issues i dunno, but i sure have issues >> with mod X. >> >> - Erwin >> >> > From mailinglists at erwinrol.com Fri Dec 9 12:43:18 2005 From: mailinglists at erwinrol.com (Erwin Rol) Date: Fri, 09 Dec 2005 13:43:18 +0100 Subject: Broken video drivers in new modular X In-Reply-To: <43997B5E.405@hhs.nl> References: <1132564932.8267.20.camel@xpc.home.erwinrol.com> <1134125494.14221.12.camel@xpc.home.erwinrol.com> <43997B5E.405@hhs.nl> Message-ID: <1134132198.14221.15.camel@xpc.home.erwinrol.com> On Fri, 2005-12-09 at 13:41 +0100, Hans de Goede wrote: > > Erwin Rol wrote: > > The radeon driver is still broken, and only works without acceleration > > (anything else causes hard lockup of the whole machine). > > Will Xorg 7.0.0R3 be available for rawhide ? > > > > Erm, my radeon 9250 works fine for me. Including DRI ppracer, this is on > x86_64 But the Radeon 9250 is a RV280 chip and not a RV370 one, I think that's why yours works and mine doesn't. Groeten, Erwin > > Regards, > > Hans > > > > - Erwin > > > > On Mon, 2005-11-21 at 10:22 +0100, Erwin Rol wrote: > >> On Mon, 2005-11-21 at 02:44 -0500, Sadda Teh wrote: > >>> Hi all, just writing to say that on my Dell Inspiron 8000 laptop > >>> (latest BIOS) with ATI Mobility M4 video the modular X vesa and r128 > >>> drivers do not work properly. > >> My Radeon locks the machine hard, meaning no network, no nothing, only > >> can press the reset/power switch. I have seen previous reports here with > >> the same problem, but there was talk about that AGP might be the > >> problem, but i have a PCIe card (01:00.0 VGA compatible controller: ATI > >> Technologies Inc RV370 5B60 [Radeon X300 (PCIE)] ). > >> That card worked fine with the old Xorg before the switch to mod-X. > >> > >>> When X is configured to use the vesa driver it comes up, but the > >>> picture is distorted (looks like 2 vertical desktops overlapping one > >>> another at various points, also colors are messed up). > >> When i use the vesa driver i see things like that too. The icons of > >> applications have the wrong colors (looks like R and G and B are > >> switched) and they are also at the wrong place (shifted 20 pixels or > >> so). > >> > >> I am now running with the fbdev driver on top of the radeonfb this works > >> but is of course not optimal. > >> > >>> As for trying to use the r128 driver, X cannot even load when > >>> configured this way, it fails with an error along the lines of the > >>> r128_drv.so could not be opened. Has anyone else seen issues like this > >>> with the new modular X packages? Should I file bugs for these in > >>> x.org's bugzilla? Thanks. > >> Well if it are really the same issues i dunno, but i sure have issues > >> with mod X. > >> > >> - Erwin From andda347 at student.liu.se Fri Dec 9 12:52:58 2005 From: andda347 at student.liu.se (David Andersson) Date: Fri, 09 Dec 2005 13:52:58 +0100 Subject: gstreamer 0.10 In-Reply-To: <1134100748.11873.9.camel@localhost.localdomain> References: <1134100748.11873.9.camel@localhost.localdomain> Message-ID: <1134132779.20058.8.camel@krikkit.xn--kremla-iuad.se> On Thu, 2005-12-08 at 22:59 -0500, John (J5) Palmieri wrote: > If a significant portion > of core apps start depending on 0.10 then we can pull it in. Totem and rhythmbox have got ports to 0.10 and will most definitely be ready when Gnome 2.14 is released. I know there are patches floating around for Amarok but i'm haven't heard when they plan to officially support it. I also think it would be very good to have 'cause it's a major leap in terms of videoperformance (and audio too, the Rhythmbox port is quit a bit faster then the 0.8 version) also next gen programs like Diva (I know you will not ship it, but 3rd party reps.) will require it. Getting it into rawhide sooner than later could also mean great feedback to the developers. -------------- 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 Dec 9 14:09:41 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Fri, 09 Dec 2005 15:09:41 +0100 Subject: Broken video drivers in new modular X In-Reply-To: <1134132198.14221.15.camel@xpc.home.erwinrol.com> References: <1132564932.8267.20.camel@xpc.home.erwinrol.com> <1134125494.14221.12.camel@xpc.home.erwinrol.com> <43997B5E.405@hhs.nl> <1134132198.14221.15.camel@xpc.home.erwinrol.com> Message-ID: <43999025.5040505@hhs.nl> Erwin Rol wrote: > On Fri, 2005-12-09 at 13:41 +0100, Hans de Goede wrote: >> Erwin Rol wrote: >>> The radeon driver is still broken, and only works without acceleration >>> (anything else causes hard lockup of the whole machine). >>> Will Xorg 7.0.0R3 be available for rawhide ? >>> >> Erm, my radeon 9250 works fine for me. Including DRI ppracer, this is on >> x86_64 > > But the Radeon 9250 is a RV280 chip and not a RV370 one, I think that's > why yours works and mine doesn't. > That figures, well bugzilla is your friend then, xorg bugzilla in this case. Better wait for 7.0.0R3 first though. Regards, Hans From skvidal at phy.duke.edu Fri Dec 9 14:06:18 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 09 Dec 2005 09:06:18 -0500 Subject: yum clean bug In-Reply-To: <20051209093704.GA30811@devserv.devel.redhat.com> References: <1134074565.23944.39.camel@cutter> <20051208205137.GA10102@nsk.no-ip.org> <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> <1134078696.1536.1.camel@weasel.turre.laiskiainen.org> <1134079174.23944.48.camel@cutter> <20051208221541.GC10102@nsk.no-ip.org> <1134080580.23944.54.camel@cutter> <20051208225937.GD10102@nsk.no-ip.org> <1134087053.28503.11.camel@cutter> <20051209093704.GA30811@devserv.devel.redhat.com> Message-ID: <1134137178.29166.4.camel@cutter> On Fri, 2005-12-09 at 04:37 -0500, Alan Cox wrote: > On Thu, Dec 08, 2005 at 07:10:53PM -0500, seth vidal wrote: > > CLOSED->WONTFIX > > > > we will NOT be doing this. Here ends the discussion. > > Don't you mean > > CLOSED->GO FORK If someone wants to fork over this then there are some excellent mental health professionals they should be talking with. :) -sv From sundaram at redhat.com Fri Dec 9 14:08:39 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 09 Dec 2005 19:38:39 +0530 Subject: yum clean bug In-Reply-To: <1134137178.29166.4.camel@cutter> References: <1134074565.23944.39.camel@cutter> <20051208205137.GA10102@nsk.no-ip.org> <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> <1134078696.1536.1.camel@weasel.turre.laiskiainen.org> <1134079174.23944.48.camel@cutter> <20051208221541.GC10102@nsk.no-ip.org> <1134080580.23944.54.camel@cutter> <20051208225937.GD10102@nsk.no-ip.org> <1134087053.28503.11.camel@cutter> <20051209093704.GA30811@devserv.devel.redhat.com> <1134137178.29166.4.camel@cutter> Message-ID: <43998FE7.7060804@redhat.com> Hi >If someone wants to fork over this then there are some excellent mental >health professionals they should be talking with. :) > > Heh. Its rather unhealthy to call everyone who disagrees with this to be mental. As you can see there are different view points on it. Alteast a fork would produce code that you can use. It doesnt have to be a fork necessarily though. regards Rahul From skvidal at phy.duke.edu Fri Dec 9 14:13:57 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 09 Dec 2005 09:13:57 -0500 Subject: yum clean bug In-Reply-To: <43998FE7.7060804@redhat.com> References: <1134074565.23944.39.camel@cutter> <20051208205137.GA10102@nsk.no-ip.org> <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> <1134078696.1536.1.camel@weasel.turre.laiskiainen.org> <1134079174.23944.48.camel@cutter> <20051208221541.GC10102@nsk.no-ip.org> <1134080580.23944.54.camel@cutter> <20051208225937.GD10102@nsk.no-ip.org> <1134087053.28503.11.camel@cutter> <20051209093704.GA30811@devserv.devel.redhat.com> <1134137178.29166.4.camel@cutter> <43998FE7.7060804@redhat.com> Message-ID: <1134137637.29166.8.camel@cutter> On Fri, 2005-12-09 at 19:38 +0530, Rahul Sundaram wrote: > Hi > > >If someone wants to fork over this then there are some excellent mental > >health professionals they should be talking with. :) > > > > > Heh. Its rather unhealthy to call everyone who disagrees with this to be > mental. As you can see there are different view points on it. Alteast a > fork would produce code that you can use. It doesnt have to be a fork > necessarily though. let's be clear. I didn't call everyone who disagrees with me mental. I said anyone who wants to take over the responsibility and suffering of forking and maintaining a program b/c they don't like the cache-handling behavior is headed round the twist. -sv From mailinglists at erwinrol.com Fri Dec 9 14:17:36 2005 From: mailinglists at erwinrol.com (Erwin Rol) Date: Fri, 09 Dec 2005 15:17:36 +0100 Subject: Broken video drivers in new modular X In-Reply-To: <43999025.5040505@hhs.nl> References: <1132564932.8267.20.camel@xpc.home.erwinrol.com> <1134125494.14221.12.camel@xpc.home.erwinrol.com> <43997B5E.405@hhs.nl> <1134132198.14221.15.camel@xpc.home.erwinrol.com> <43999025.5040505@hhs.nl> Message-ID: <1134137856.14221.21.camel@xpc.home.erwinrol.com> On Fri, 2005-12-09 at 15:09 +0100, Hans de Goede wrote: > That figures, well bugzilla is your friend then, xorg bugzilla in this > case. Better wait for 7.0.0R3 first though. Yep and that's why i was asking if 7R3 will be available on Rawhide anytime soon. Especially since the Xorg release plan is like; * 14 Dec 2005: Finalize tree (only documentation changes allowed) * 21 Dec 2005: X11R6.9/X11R7 Release So this leaves very little time to file a bug against 7R3 to be fixed in R7-final. - Erwin From d.jacobfeuerborn at conversis.de Fri Dec 9 14:54:57 2005 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Fri, 09 Dec 2005 15:54:57 +0100 Subject: Broken video drivers in new modular X In-Reply-To: <1134132198.14221.15.camel@xpc.home.erwinrol.com> References: <1132564932.8267.20.camel@xpc.home.erwinrol.com> <1134125494.14221.12.camel@xpc.home.erwinrol.com> <43997B5E.405@hhs.nl> <1134132198.14221.15.camel@xpc.home.erwinrol.com> Message-ID: <43999AC1.3000904@conversis.de> Erwin Rol wrote: > On Fri, 2005-12-09 at 13:41 +0100, Hans de Goede wrote: >> Erwin Rol wrote: >>> The radeon driver is still broken, and only works without acceleration >>> (anything else causes hard lockup of the whole machine). >>> Will Xorg 7.0.0R3 be available for rawhide ? >>> >> Erm, my radeon 9250 works fine for me. Including DRI ppracer, this is on >> x86_64 > > But the Radeon 9250 is a RV280 chip and not a RV370 one, I think that's > why yours works and mine doesn't. I'm running the radeon driver on a Radeon 9500pro (R300) and I don't see any crashes but the performance went downhill quite dramatically about a week or two after the modular release in rawhide. I'm not sure what the cause of this is but profiling shows that the system spends a lot of time in the function "fbCopyAreammx" which looks a bit odd to me. Right after the modular release in rawhide things worked extremely well though and modular-x + Composite (without shadows and/or translucency though) worked just as smooth as any WindowsXP desktop out there. That's no longer the case right now. Regards, Dennis From d.jacobfeuerborn at conversis.de Fri Dec 9 14:59:58 2005 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Fri, 09 Dec 2005 15:59:58 +0100 Subject: gstreamer 0.10 In-Reply-To: <1134100748.11873.9.camel@localhost.localdomain> References: <1134100748.11873.9.camel@localhost.localdomain> Message-ID: <43999BEE.6030002@conversis.de> John (J5) Palmieri wrote: > On Thu, 2005-12-08 at 13:54 -0600, Jason Dravet wrote: >> Is gstreamer 0.10 going to be in FC5T2? > > That depends if we have applications that are ported to it. As it is I > would say that it should go into extras first. If a significant portion > of core apps start depending on 0.10 then we can pull it in. I tried using banshee which now has an experimental 0.10 backend but on startup in complains that it cannot find a file "/tmp/dbus-xxxxxx". It probably got that name from $DBUS_SESSION_BUS_ADDRESS but there are no files called like that in the tmp directory. Could this be a bug in DBus? Regards, Dennis From jkeating at j2solutions.net Fri Dec 9 15:05:24 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 09 Dec 2005 07:05:24 -0800 Subject: yum clean bug In-Reply-To: References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <43991511.4020705@n-man.com> <1134106494.3423.19.camel@ender> Message-ID: <1134140724.3010.21.camel@yoda.loki.me> On Fri, 2005-12-09 at 07:21 +0100, Thomas M Steenholdt wrote: > Either that or just put in the CLEAN section of the man page that this > is required for disabled and non-existing repos. The yum bugzilla awaits your RFE for the man page. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From jkeating at j2solutions.net Fri Dec 9 15:09:41 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 09 Dec 2005 07:09:41 -0800 Subject: yum clean bug In-Reply-To: References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> Message-ID: <1134140981.3010.26.camel@yoda.loki.me> On Fri, 2005-12-09 at 01:02 -0800, Panu Matilainen wrote: > I guess can live with that, it just feels rather counterintuitive to me to > have to mess with repo settings to clean cache data. If somebody can come > up with a real, sane usage scenario why leaving disabled repos alone on > clean operations is a good idea it might help making it feel a bit less > odd. :) I constantly use repos that are on slow links. So these repos are disabled by default, but at times I run with enabled. I never want this cache to be removed as it would take forever and a day to redownload all the info. So for me, I'd rather 'yum clean all' cleans ALL the enabled repos. It really is 6 of one, half dozen of the other. Either 'clean all' means All enabled repos, or disabled repo means 'only disable from install, but go ahead and mess w/ the cache'. The upstream developer has indicated which side he stands on, and which side he'll allow his code to do. End of story. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From jspaleta at gmail.com Fri Dec 9 15:10:00 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 9 Dec 2005 10:10:00 -0500 Subject: yum clean bug In-Reply-To: <4399358A.2060005@laposte.net> References: <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <4399358A.2060005@laposte.net> Message-ID: <604aa7910512090710q2b72018ao68307cc24eafa3f0@mail.gmail.com> On 12/9/05, Nicolas Mailhot wrote: > yum clean all behaviour may be familiar to yum developpers, but it's > contrary to both English (all is no longer everything) you are absolutely right.. we should make it clearer. To do any operation it should require a full proper english sentence. yum please clean ALL the cached data of the configured repositories yum please clean ALL the cached data of the enabled repositories yum please clean ALL the cached data of the disabled repositories yum pretty please clean ALL of the packages in all configured repositories No more cmdline switches that confuse people across the different operations that intuition dictates be used inconsistently. Someone should jump on bolting in a yum plugin for natural language input. Though I'm personally holding out for the directly neural interface so i can build the mind-reading plugin. > and accepted > Linux standards (cache is no longer disposable) I'll go ahead and file an RFE for the fedora core yum package to set cachedir explicitly to cachedir=/var/spool/yum in fedora core so we can avoid this argument in the future. Though I might suggest a new directory spache that is part spool and part cache... or maybe the directory should be called cool for part cache and part spool. -jef"You got your cache in my spool... you got your spool in my cache....mmmmm."spaleta From jkeating at j2solutions.net Fri Dec 9 15:18:35 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 09 Dec 2005 07:18:35 -0800 Subject: yum clean bug In-Reply-To: <4399358A.2060005@laposte.net> References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <4399358A.2060005@laposte.net> Message-ID: <1134141515.3010.34.camel@yoda.loki.me> On Fri, 2005-12-09 at 08:43 +0100, Nicolas Mailhot wrote: > and accepted > Linux standards (cache is no longer disposable) Case in point. Upstream repository completely goes away, or goes offline for a long period of time. I disable the repo in my configs, but from time to time I still need access to the rpms and info that is sitting in the cache dir. (do a cache only operation using this repo and others). I don't want yum removing this out from under me, especially if I have the repo disabled. The question isn't whether or not the cache is disposable, the question is if I am ready for yum to dispose of it in a non intuitive way. I disabled a repo, I don't want to see any operations involved with disabling this repo. Doing operations in regard to this repo when it is disabled seems very counterintuitive to me. Thus when I do a clear all, I want all cleared from enabled repos. Period. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From nicolas.mailhot at laposte.net Fri Dec 9 15:34:20 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 9 Dec 2005 16:34:20 +0100 (CET) Subject: yum clean bug In-Reply-To: <604aa7910512090710q2b72018ao68307cc24eafa3f0@mail.gmail.com> References: <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <4399358A.2060005@laposte.net> <604aa7910512090710q2b72018ao68307cc24eafa3f0@mail.gmail.com> Message-ID: <22905.192.54.193.25.1134142460.squirrel@rousalka.dyndns.org> On Ven 9 d?cembre 2005 16:10, Jeff Spaleta wrote: >> and accepted >> Linux standards (cache is no longer disposable) > > I'll go ahead and file an RFE for the fedora core yum package to set > cachedir explicitly to cachedir=/var/spool/yum in fedora core so we > can avoid this argument in the future. Though I might suggest a new > directory > spache that is part spool and part cache... or maybe the directory > should be called cool for part cache and part spool. It says a lot about the yum developpers state of mind that even a direct quote from a well-accepted standard attracts this kind of response. Guys, if you don't want to listen to others, and have only abuse to offer, don't answer questions at all. Why do you think every single yum thread is degenerating lately ? Every single poster but you is brain-damaged ? -- Nicolas Mailhot From nicolas.mailhot at laposte.net Fri Dec 9 15:37:07 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 9 Dec 2005 16:37:07 +0100 (CET) Subject: yum clean bug In-Reply-To: <1134141515.3010.34.camel@yoda.loki.me> References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <4399358A.2060005@laposte.net> <1134141515.3010.34.camel@yoda.loki.me> Message-ID: <28475.192.54.193.25.1134142627.squirrel@rousalka.dyndns.org> On Ven 9 d?cembre 2005 16:18, Jesse Keating wrote: > On Fri, 2005-12-09 at 08:43 +0100, Nicolas Mailhot wrote: >> and accepted >> Linux standards (cache is no longer disposable) > > Case in point. Upstream repository completely goes away, or goes > offline for a long period of time. I disable the repo in my configs, > but from time to time I still need access to the rpms and info that is > sitting in the cache dir. (do a cache only operation using this repo > and others). I don't want yum removing this out from under me, > especially if I have the repo disabled. So you want a spool not a cache. Any file in /var/cache can be nuked at any time, that's how /var/cache is defined. I won't quote the FHS again, you can read it yourself. -- Nicolas Mailhot From n0dalus+redhat at gmail.com Fri Dec 9 15:39:32 2005 From: n0dalus+redhat at gmail.com (n0dalus) Date: Sat, 10 Dec 2005 02:09:32 +1030 Subject: yum clean bug In-Reply-To: <1134141515.3010.34.camel@yoda.loki.me> References: <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <4399358A.2060005@laposte.net> <1134141515.3010.34.camel@yoda.loki.me> Message-ID: <6280325c0512090739y6fb8d79bt1f760c1e0032c338@mail.gmail.com> On 12/10/05, Jesse Keating wrote: > [...] > > The question isn't whether or not the cache is disposable, the question > is if I am ready for yum to dispose of it in a non intuitive way. I > disabled a repo, I don't want to see any operations involved with > disabling this repo. Doing operations in regard to this repo when it is > disabled seems very counterintuitive to me. Thus when I do a clear all, > I want all cleared from enabled repos. Period. > I think it is clear that there are people interpreting the meaning of 'all' differently. To some people, 'all' really means all. To other people, 'all' means a selection of things they have set from a slightly more encompassing 'all'. I know that the devs don't want to add "useless" new features to yum, but personally having a few extra options like this really wouldn't go astray, and would be very useful in lots of cases: yum clean enabled yum clean disabled By all means tell us to hide away these new features in yum-utils (if anyone wants to code them), but I don't think the issue should just be dismissed. n0dalus. From skvidal at phy.duke.edu Fri Dec 9 15:42:39 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 09 Dec 2005 10:42:39 -0500 Subject: yum clean bug In-Reply-To: <22905.192.54.193.25.1134142460.squirrel@rousalka.dyndns.org> References: <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <4399358A.2060005@laposte.net> <604aa7910512090710q2b72018ao68307cc24eafa3f0@mail.gmail.com> <22905.192.54.193.25.1134142460.squirrel@rousalka.dyndns.org> Message-ID: <1134142959.30757.4.camel@cutter> > It says a lot about the yum developpers state of mind that even a direct > quote from a well-accepted standard attracts this kind of response. > Guys, > if you don't want to listen to others, and have only abuse to offer, don't > answer questions at all. Why do you think every single yum thread is > degenerating lately ? Every single poster but you is brain-damaged ? The only yum developers who have spoken in this thread have been Panu and Me. I'm sorry we don't agree but that happens sometime. Luckily you don't have to worry about what I do or do not believe for two reasons: 1. it's open source you can do what you want 2. Menno Smits and other folks have given yum a lovely Plugin interface that makes this problem utterly trivial to get around. I would highly encourage you to write a make-it-clean plugin that, for example, could run after the transaction finishes and cleans up all the rpms in the /var/cache/yum directory, if you wish. Seriously, write the plugin, send it to yum-devel list. -sv From sundaram at redhat.com Fri Dec 9 15:41:41 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 09 Dec 2005 21:11:41 +0530 Subject: yum clean bug In-Reply-To: <6280325c0512090739y6fb8d79bt1f760c1e0032c338@mail.gmail.com> References: <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <4399358A.2060005@laposte.net> <1134141515.3010.34.camel@yoda.loki.me> <6280325c0512090739y6fb8d79bt1f760c1e0032c338@mail.gmail.com> Message-ID: <4399A5B5.90603@redhat.com> Hi >By all means tell us to hide away these new features in yum-utils (if >anyone wants to code them), but I don't think the issue should just be >dismissed. > > I think its a pretty good idea to use yum-utils as a gateway for new features in Yum. Only thing thats waiting on is code. regards Rahul From jkeating at j2solutions.net Fri Dec 9 15:42:56 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 09 Dec 2005 07:42:56 -0800 Subject: yum clean bug In-Reply-To: <22905.192.54.193.25.1134142460.squirrel@rousalka.dyndns.org> References: <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <4399358A.2060005@laposte.net> <604aa7910512090710q2b72018ao68307cc24eafa3f0@mail.gmail.com> <22905.192.54.193.25.1134142460.squirrel@rousalka.dyndns.org> Message-ID: <1134142976.3010.39.camel@yoda.loki.me> On Fri, 2005-12-09 at 16:34 +0100, Nicolas Mailhot wrote: > It says a lot about the yum developpers state of mind that even a direct > quote from a well-accepted standard attracts this kind of response. The standards don't say squat about WHAT removes the cache. Yums cache is completely regeneratable, provided that the repository is still available. However the yum developers stance is that yum itself will not take the chance that the user really doesn't want that cache laying around, so it leaves it up to THE USER to clear disabled / removed repo cache. What is so hard about this to understand? > Guys, > if you don't want to listen to others, and have only abuse to offer, don't > answer questions at all. Why do you think every single yum thread is > degenerating lately ? Every single poster but you is brain-damaged ? The only 'abuse' I see is folks yelling at the yum developer because he refuses to implement a features he finds dangerous, and does not wish to get the tonnes of email when said dangerous feature actually does something the user didn't wish. The abuse comes after the developer says no, then the user gets all in a huff and starts throwing accusations around as well as names at times. Give me a friggin break. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From skvidal at phy.duke.edu Fri Dec 9 15:43:58 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 09 Dec 2005 10:43:58 -0500 Subject: yum clean bug In-Reply-To: <1134142959.30757.4.camel@cutter> References: <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <4399358A.2060005@laposte.net> <604aa7910512090710q2b72018ao68307cc24eafa3f0@mail.gmail.com> <22905.192.54.193.25.1134142460.squirrel@rousalka.dyndns.org> <1134142959.30757.4.camel@cutter> Message-ID: <1134143038.30757.7.camel@cutter> On Fri, 2005-12-09 at 10:42 -0500, seth vidal wrote: > > It says a lot about the yum developpers state of mind that even a direct > > quote from a well-accepted standard attracts this kind of response. > > Guys, > > if you don't want to listen to others, and have only abuse to offer, don't > > answer questions at all. Why do you think every single yum thread is > > degenerating lately ? Every single poster but you is brain-damaged ? > > The only yum developers who have spoken in this thread have been Panu > and Me. > > I'm sorry we don't agree but that happens sometime. Luckily you don't We in this sentence is "You and I" not Panu and me, though, notably he and I do not agree on this, either. :) -sv From jkeating at j2solutions.net Fri Dec 9 15:44:21 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 09 Dec 2005 07:44:21 -0800 Subject: yum clean bug In-Reply-To: <28475.192.54.193.25.1134142627.squirrel@rousalka.dyndns.org> References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <4399358A.2060005@laposte.net> <1134141515.3010.34.camel@yoda.loki.me> <28475.192.54.193.25.1134142627.squirrel@rousalka.dyndns.org> Message-ID: <1134143061.3010.41.camel@yoda.loki.me> On Fri, 2005-12-09 at 16:37 +0100, Nicolas Mailhot wrote: > So you want a spool not a cache. > Any file in /var/cache can be nuked at any time, that's how /var/cache is > defined. I won't quote the FHS again, you can read it yourself. No I don't want a spool. This isn't spool files. I want to decide when the cache gets nuked. I don't want an application making assumptions on my behalf. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From johnp at redhat.com Fri Dec 9 15:45:54 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Fri, 09 Dec 2005 10:45:54 -0500 Subject: gstreamer 0.10 In-Reply-To: <43999BEE.6030002@conversis.de> References: <1134100748.11873.9.camel@localhost.localdomain> <43999BEE.6030002@conversis.de> Message-ID: <1134143154.11873.55.camel@localhost.localdomain> On Fri, 2005-12-09 at 15:59 +0100, Dennis Jacobfeuerborn wrote: > > John (J5) Palmieri wrote: > > On Thu, 2005-12-08 at 13:54 -0600, Jason Dravet wrote: > >> Is gstreamer 0.10 going to be in FC5T2? > > > > That depends if we have applications that are ported to it. As it is I > > would say that it should go into extras first. If a significant portion > > of core apps start depending on 0.10 then we can pull it in. > > I tried using banshee which now has an experimental 0.10 backend but on > startup in complains that it cannot find a file "/tmp/dbus-xxxxxx". It > probably got that name from $DBUS_SESSION_BUS_ADDRESS but there are no > files called like that in the tmp directory. Could this be a bug in DBus? Most likely a bug in the Mono bindings since we just broke some API/ABI's. Also check if your system bus is running also . Session bus uses abstract sockets which don't appear in the file system. -- John (J5) Palmieri From jkeating at j2solutions.net Fri Dec 9 15:49:20 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 09 Dec 2005 07:49:20 -0800 Subject: yum clean bug In-Reply-To: <6280325c0512090739y6fb8d79bt1f760c1e0032c338@mail.gmail.com> References: <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <4399358A.2060005@laposte.net> <1134141515.3010.34.camel@yoda.loki.me> <6280325c0512090739y6fb8d79bt1f760c1e0032c338@mail.gmail.com> Message-ID: <1134143360.3010.46.camel@yoda.loki.me> On Sat, 2005-12-10 at 02:09 +1030, n0dalus wrote: > > I think it is clear that there are people interpreting the meaning of > 'all' differently. > To some people, 'all' really means all. To other people, 'all' means a > selection of things they have set from a slightly more encompassing > 'all'. It is extremely difficult to interpret one word the same across all people/features. It's like determining what the meaning of 'is' is. (ok, bad joke). Seriously as Jef states, unless we do spoken word translation, the simple terms will just need to be defined in man pages and whatnot. I'm sure Seth would be perfectly ameanable to a man page patch that clearly defines what the term 'all' means in a given context, such as a clean action, or within yum as a whole. Within yum, the term 'all' refers to all the enabled repos. (see, all gets used there too!) > I know that the devs don't want to add "useless" new features > to yum, but personally having a few extra options like this really > wouldn't go astray, and would be very useful in lots of cases: > yum clean enabled > yum clean disabled > > By all means tell us to hide away these new features in yum-utils (if > anyone wants to code them), but I don't think the issue should just be > dismissed. Please do. Code speaks much louder than words, and yum-utils is a great way to get new features into something usable. Think of yum-utils something like Fedora Extras. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From icon at fedoraproject.org Fri Dec 9 15:49:27 2005 From: icon at fedoraproject.org (Konstantin Ryabitsev) Date: Fri, 09 Dec 2005 10:49:27 -0500 Subject: yum clean bug In-Reply-To: <6280325c0512090739y6fb8d79bt1f760c1e0032c338@mail.gmail.com> References: <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <4399358A.2060005@laposte.net> <1134141515.3010.34.camel@yoda.loki.me> <6280325c0512090739y6fb8d79bt1f760c1e0032c338@mail.gmail.com> Message-ID: <1134143367.3268.5.camel@localhost.localdomain> On Sat, 2005-10-12 at 02:09 +1030, n0dalus wrote: > yum clean enabled > yum clean disabled How about: "yum clean all": operates on enabled-only repositories "yum --enablerepo=* clean all": cleans all defined repositories, as (will be) mentioned in the manpage "yum clean cruft": removes directories from cachedir that aren't defined in config files This would only require ONE additional logic structure with simple code -- simply a more safe rewrite of my 4-line shell script that I have sent yesterday. Regards, -- Konstantin Ryabitsev McGill University WSG Montr?al, Qu?bec From bbbush.yuan at gmail.com Fri Dec 9 15:50:36 2005 From: bbbush.yuan at gmail.com (Yuan Yijun) Date: Fri, 9 Dec 2005 23:50:36 +0800 Subject: yum clean bug In-Reply-To: <28475.192.54.193.25.1134142627.squirrel@rousalka.dyndns.org> References: <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <4399358A.2060005@laposte.net> <1134141515.3010.34.camel@yoda.loki.me> <28475.192.54.193.25.1134142627.squirrel@rousalka.dyndns.org> Message-ID: <76e72f800512090750y1f3181ccm@mail.gmail.com> 2005/12/9, Nicolas Mailhot : > > > So you want a spool not a cache. > Any file in /var/cache can be nuked at any time, that's how /var/cache is > defined. I won't quote the FHS again, you can read it yourself. > execute: ls /var/cache result: alchemist/ gstreamer-0.8/ logwatch/ man/ mod_proxy/ samba/ yum/ did you ever heard of "gstreamer-properties clean all" or "man --clean all"? -- bbbush ^_^ From jspaleta at gmail.com Fri Dec 9 16:24:18 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 9 Dec 2005 11:24:18 -0500 Subject: yum clean bug In-Reply-To: <6280325c0512090739y6fb8d79bt1f760c1e0032c338@mail.gmail.com> References: <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <4399358A.2060005@laposte.net> <1134141515.3010.34.camel@yoda.loki.me> <6280325c0512090739y6fb8d79bt1f760c1e0032c338@mail.gmail.com> Message-ID: <604aa7910512090824y2ef8919x2e0925a57128b610@mail.gmail.com> On 12/9/05, n0dalus wrote: > yum clean enabled > yum clean disabled you are duplicating the existing --enablerepo and --disablerepo functionality that already works in a more general way. In the case of clean... "all" means combine ALL of the possible clean aguments yum clean understands packages headers metadata cache dbcache ...together these arguments combine to form Voltron!..err I mean.. the "all" argument you can either write "yum clean packages headers metadata cache dbcache" or you can write "yum clean all" Both ways of writing it do the exact same thing. "all"=="all of the clean arguments" If "all" were to by default work on more than just the enabled repos, then all the other clean arguments would by default need to do that. "yum clean metadata" would need to remove the metadata for any subdirectory in cache by default regardless of its enabled or configured state. "yum clean packages" would by default need to remove all packages in all subdirs regardless of enabled or configured state. The "all" command does not change the nature of how clean deals with enabled/disabled/configured, it simply combines "all" the clean arguments into a single command. Every operation that clean understands, all of them, are in the context of what the enabled repository state is at the moment. Right now, yum's clean command treats repo state exactly the same way as yum's other commands. They all respond to --enablerepo and --disablerepo to add and remove configured repositories from the calculation. Let's review how many yum commands exist: < update | install | info | remove | list | clean | provides | search | check-update | groupinstall | groupupdate | grouplist | groupinfo | groupremove | makecache | localinstall | erase | upgrade | whatprovides | localupdate | resolvedep | shell | deplist > In the context of yum's operation making clean behave differently with regard to how enabledrepo and disablerepo are handled is a big glaring inconsistency. We can 'all' fight over how poorly chosen the english word 'all' is 'all' live long day...as we struggle to cram a full english sentence into the shorthand of cmdline operations. English is such a precise language after all, there is never ever a need for contextual information to understand a single sentence. We might as well 'all' fight over how ironically unintuitively 'yum list extras' is. The only situation not currently covered by available functionality is the situation of a repository being unconfigured so that yum has no configuration information for that repository at all. Is that somthing yum should clean up after? Or is that the responsibility of whatever mechanism unconfigured the repository and blinded yum? -jef"Valid English sentence: Buffalo buffalo buffalo Buffalo buffalo"spaleta From fraser at renewedheart.org Fri Dec 9 16:24:07 2005 From: fraser at renewedheart.org (Fraser Hess) Date: Fri, 09 Dec 2005 09:24:07 -0700 Subject: mailman 2.1.6 Message-ID: <4399AFA7.5000709@renewedheart.org> I am experiencing a bug in mailman 2.1.5 that has been documented and fixed in mailman 2.1.6. More info on the bug/patch: http://mail.python.org/pipermail/mailman-coders/2005-February/001578.html http://sourceforge.net/project/shownotes.php?release_id=331123&group_id=103 I noticed that mailman 2.1.6 is in the development repo. What can I do to help move it along to release for FC4? Alternatively, should the current build of 2.1.5 be patch to solve my issue? Fraser Hess From sundaram at redhat.com Fri Dec 9 16:28:38 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 09 Dec 2005 21:58:38 +0530 Subject: mailman 2.1.6 In-Reply-To: <4399AFA7.5000709@renewedheart.org> References: <4399AFA7.5000709@renewedheart.org> Message-ID: <4399B0B6.7030703@redhat.com> Fraser Hess wrote: > I am experiencing a bug in mailman 2.1.5 that has been documented and > fixed in mailman 2.1.6. > More info on the bug/patch: > http://mail.python.org/pipermail/mailman-coders/2005-February/001578.html > http://sourceforge.net/project/shownotes.php?release_id=331123&group_id=103 > > I noticed that mailman 2.1.6 is in the development repo. What can I > do to help move it along to release for FC4? File a bug report against the package requesting an update with the above information in http://bugzilla.redhat.com. Thanks regards Rahul From pertusus at free.fr Fri Dec 9 16:44:54 2005 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 9 Dec 2005 17:44:54 +0100 Subject: g77/gfortran incompatibilities Message-ID: <20051209164454.GA7447@free.fr> Hello, I am currently annoyed by the gfortran/g77 incompatibilities. Indeed gfortran has still some regressions with regard with g77, especially some missing intrinsics. Some are listed in the g77 regressions meta-bug here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292 some are not listed (getarg, imag). So there is still a need for g77 to build some code (for example the cernlib in fedora extras). Now the trouble is that code compiled with g77 and gfortran are not binary compatible. I have been told that compiling using g77 with -fno-f2c leads to compatibility with gfortran. Is it the case? If it is the case, I think that all the libraries compiled with g77 in fedora extras (is there any fortran in fedora core?) should be compiled with -fno-f2c with the issue that all the code to be compiled against those libraries should also be compiled with -fno-f2c. Does this make sense? -- Pat From jbarnes at virtuousgeek.org Fri Dec 9 16:39:30 2005 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Fri, 9 Dec 2005 08:39:30 -0800 Subject: kpdf disappeared? In-Reply-To: <200512081208.57646.jbarnes@virtuousgeek.org> References: <200512081208.57646.jbarnes@virtuousgeek.org> Message-ID: <200512090839.30555.jbarnes@virtuousgeek.org> On Thursday, December 8, 2005 12:08 pm, Jesse Barnes wrote: > kpdf seems to have disappeared since my upgrade. I googled around to > see if it was removed for some reason, but didn't come up with > anything. The kdegraphics source package seems to include it, but the > binary package doesn't, and the changelog doesn't mention any reason > why it would be omitted. > > What's up? In case anyone's curious: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173836 Apparently kpdf doesn't get along with modular X. Hope it's fixed soon! Jesse From czar at czarc.net Fri Dec 9 16:46:04 2005 From: czar at czarc.net (Gene C.) Date: Fri, 9 Dec 2005 11:46:04 -0500 Subject: yum clean bug In-Reply-To: <1134079174.23944.48.camel@cutter> References: <1134078696.1536.1.camel@weasel.turre.laiskiainen.org> <1134079174.23944.48.camel@cutter> Message-ID: <200512091146.04282.czar@czarc.net> On Thursday 08 December 2005 16:59, seth vidal wrote: > On Thu, 2005-12-08 at 23:51 +0200, Panu Matilainen wrote: > > On Thu, 2005-12-08 at 15:55 -0500, Jeff Spaleta wrote: > > > On 12/8/05, Luciano Miguel Ferreira Rocha wrote: > > > > Yes. Because I'm doing cache operations, not repository operations. > > > > Or rather, that's what I thought I was doing, so it would be > > > > intuitive to me. > > > > > > So for completeness what your saying is that you think > > > yum clean packages ? should clean all packages from all enabled and > > > disabled repos by default? > > > > > > and yum clean headers ?should clean all headers from all enabled and > > > disabled repos by default? > > > > Well, I actually think it should. > > Seriously? That seems completely backward to me. I guess to most of us it seems that the intuitive (expected) action is that "clean headers" would clean ALL headers regardless of repository status and similarly "clean all" would clean up everything. One question, would yum --enablerepo='*' clean all clean up everything? If the above would work, then I believe this would meet our needs. However, the man page should be updated to add this info and be clearer that only enabled repos are process by "yum clean". -- Gene From jkeating at j2solutions.net Fri Dec 9 16:54:49 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 09 Dec 2005 08:54:49 -0800 Subject: yum clean bug In-Reply-To: <200512091146.04282.czar@czarc.net> References: <1134078696.1536.1.camel@weasel.turre.laiskiainen.org> <1134079174.23944.48.camel@cutter> <200512091146.04282.czar@czarc.net> Message-ID: <1134147289.3010.56.camel@yoda.loki.me> On Fri, 2005-12-09 at 11:46 -0500, Gene C. wrote: > One question, would > yum --enablerepo='*' clean all > clean up everything? Only if the repo is still listed, and hasn't changed names. Yum uses repo information to figure out which directory in /var/cache/yum/ to nuke. Remove the repo file, can't use yum to clear the cache. Repo renames? Can't use yum to clear the cache. These tasks are beyond the acceptable 'guess' range of yum, and should be handled by a human. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From czar at czarc.net Fri Dec 9 17:01:25 2005 From: czar at czarc.net (Gene C.) Date: Fri, 9 Dec 2005 12:01:25 -0500 Subject: yum clean bug In-Reply-To: <1134137178.29166.4.camel@cutter> References: <20051209093704.GA30811@devserv.devel.redhat.com> <1134137178.29166.4.camel@cutter> Message-ID: <200512091201.25425.czar@czarc.net> On Friday 09 December 2005 09:06, seth vidal wrote: > On Fri, 2005-12-09 at 04:37 -0500, Alan Cox wrote: > > On Thu, Dec 08, 2005 at 07:10:53PM -0500, seth vidal wrote: > > > CLOSED->WONTFIX > > > > > > we will NOT be doing this. Here ends the discussion. > > > > Don't you mean > > > > CLOSED->GO FORK > > If someone wants to fork over this then there are some excellent mental > health professionals they should be talking with. :) No, we (or at least I) do NOT want to fork this and we do appreciate your efforts. However, we do need to understand how yum works and how to get it to do want we need done. When it operates in a non-intuitive manner, we ask questions. The man-page documentation implies (to us) a way of operation that is different from how yum actually works. OK, fine. Change the doc to reflect how it works. If we need to do yum --enablerepo='*' clean all then fine ... just document that is how we need to do things. -- Gene From n0dalus+redhat at gmail.com Fri Dec 9 17:06:42 2005 From: n0dalus+redhat at gmail.com (n0dalus) Date: Sat, 10 Dec 2005 03:36:42 +1030 Subject: yum clean bug In-Reply-To: <4399A5B5.90603@redhat.com> References: <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <4399358A.2060005@laposte.net> <1134141515.3010.34.camel@yoda.loki.me> <6280325c0512090739y6fb8d79bt1f760c1e0032c338@mail.gmail.com> <4399A5B5.90603@redhat.com> Message-ID: <6280325c0512090906k7a8ffa0fn43e71eedf557acdd@mail.gmail.com> On 12/10/05, Rahul Sundaram wrote: > [...] > > I think its a pretty good idea to use yum-utils as a gateway for new > features in Yum. Only thing thats waiting on is code. > > regards > Rahul > I think it is a good idea too. However I feel a distinct lack of motivation for submitting a new feature when the developers just dismiss ideas casually and say that feature will never have a chance of inclusion. So even if everyone that uses a new plugin from yum-utils says it is the best thing since sliced bread and they all want it in yum, it probably won't ever see the light of day -- after all, the developers said it would never be considered, right? Will yum-utils then just become a place to stash any unwanted features? On the other hand, if the developers said (and actually meant it) "The idea could be improved a bit, but I think it has some merit when I look at it from your perspective. You're welcome to try submitting it to yum-utils and we'll see if people like it. Thank you for suggesting a new feature and doing your part in keeping a good open source project alive."; the person would have a sense that they could contribute, and they would be motivated to write their plugin in the best possible way to see if people will like it. Please note, this is not aimed at any particular developers, or even at yum in particular, but it's just a principle that could apply to any open source project. As a side note, how many people actually have yum-utils and are aware of all it's features? There is once again very little motivation to submit to something that won't be used or even known about. Maybe the yum-utils structure could be improved to better incorporate plugins, or maybe a whole new yum-plugins package could be made. It would be nice to have a man page as well to (tersely if necessary) describe all the included features. Please note that I would be happy to attempt such a project if people think it is worthwhile. n0dalus. From czar at czarc.net Fri Dec 9 17:08:12 2005 From: czar at czarc.net (Gene C.) Date: Fri, 9 Dec 2005 12:08:12 -0500 Subject: yum clean bug In-Reply-To: <1134147289.3010.56.camel@yoda.loki.me> References: <200512091146.04282.czar@czarc.net> <1134147289.3010.56.camel@yoda.loki.me> Message-ID: <200512091208.12099.czar@czarc.net> On Friday 09 December 2005 11:54, Jesse Keating wrote: > On Fri, 2005-12-09 at 11:46 -0500, Gene C. wrote: > > One question, would > > ? ? yum ?--enablerepo='*' clean all > > clean up everything? > > Only if the repo is still listed, and hasn't changed names. ?Yum uses > repo information to figure out which directory in /var/cache/yum/ to > nuke. ?Remove the repo file, can't use yum to clear the cache. ?Repo > renames? ?Can't use yum to clear the cache. ?These tasks are beyond the > acceptable 'guess' range of yum, and should be handled by a human. Agree! -- Gene From czar at czarc.net Fri Dec 9 17:16:10 2005 From: czar at czarc.net (Gene C.) Date: Fri, 9 Dec 2005 12:16:10 -0500 Subject: yum clean bug In-Reply-To: <1134140724.3010.21.camel@yoda.loki.me> References: <1134140724.3010.21.camel@yoda.loki.me> Message-ID: <200512091216.10091.czar@czarc.net> On Friday 09 December 2005 10:05, Jesse Keating wrote: > On Fri, 2005-12-09 at 07:21 +0100, Thomas M Steenholdt wrote: > > Either that or just put in the CLEAN section of the man page that this > > is required for disabled and non-existing repos. > > The yum bugzilla awaits your RFE for the man page. It is not clear to me that the changes needed to the yum man page are an RFE as oppose to a documentation "error" in that the current description implies different operation (at least to some individuals) than what yum really implements. -- Gene From jkeating at j2solutions.net Fri Dec 9 17:23:15 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 09 Dec 2005 09:23:15 -0800 Subject: yum clean bug In-Reply-To: <200512091216.10091.czar@czarc.net> References: <1134140724.3010.21.camel@yoda.loki.me> <200512091216.10091.czar@czarc.net> Message-ID: <1134148995.3010.63.camel@yoda.loki.me> On Fri, 2005-12-09 at 12:16 -0500, Gene C. wrote: > It is not clear to me that the changes needed to the yum man page are an RFE > as oppose to a documentation "error" in that the current description implies > different operation (at least to some individuals) than what yum really > implements. Well as pointed out, the 'all' in yum clean all does not reference repositories, rather cache items. So all does exactly what it is supposed to do, cleans all the cache items. The clean action itself is what acts upon active repositories. It stands to reason that the documentation on the clean action could use an enhancement to mention that it works only on existing/enabled repositories. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From nicolas.mailhot at laposte.net Fri Dec 9 17:27:44 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 09 Dec 2005 18:27:44 +0100 Subject: yum clean bug In-Reply-To: <1134142976.3010.39.camel@yoda.loki.me> References: <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <4399358A.2060005@laposte.net> <604aa7910512090710q2b72018ao68307cc24eafa3f0@mail.gmail.com> <22905.192.54.193.25.1134142460.squirrel@rousalka.dyndns.org> <1134142976.3010.39.camel@yoda.loki.me> Message-ID: <4399BE90.7080809@laposte.net> Jesse Keating wrote: > On Fri, 2005-12-09 at 16:34 +0100, Nicolas Mailhot wrote: >> It says a lot about the yum developpers state of mind that even a direct >> quote from a well-accepted standard attracts this kind of response. > > The standards don't say squat about WHAT removes the cache. Yums cache > is completely regeneratable, provided that the repository is still > available. However the yum developers stance is that yum itself will > not take the chance that the user really doesn't want that cache laying > around, so it leaves it up to THE USER to clear disabled / removed repo > cache. What is so hard about this to understand? If yum is so concerned about this "data" safety why is it storing it in a filesystem tree specifically reserved for stuff that can be removed without notice? But anyway this was not my point. >> Guys, >> if you don't want to listen to others, and have only abuse to offer, don't >> answer questions at all. Why do you think every single yum thread is >> degenerating lately ? Every single poster but you is brain-damaged ? > > The only 'abuse' I see When people take shots at quotes from a neutral text like the FHS, that shows they're only interested in harassing people that disagree with Seth, and have nothing to contribute to the discussion itself. (I imagine it's as embarrassing for Seth as having an "helpful" friend yell the sky is green because you're disagreeing with someone who noted in the course of his argument the sky is blue) -- Nicolas Mailhot From nicolas.mailhot at laposte.net Fri Dec 9 17:30:38 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 09 Dec 2005 18:30:38 +0100 Subject: yum clean bug In-Reply-To: <1134143061.3010.41.camel@yoda.loki.me> References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <4399358A.2060005@laposte.net> <1134141515.3010.34.camel@yoda.loki.me> <28475.192.54.193.25.1134142627.squirrel@rousalka.dyndns.org> <1134143061.3010.41.camel@yoda.loki.me> Message-ID: <4399BF3E.6040206@laposte.net> Jesse Keating wrote: > On Fri, 2005-12-09 at 16:37 +0100, Nicolas Mailhot wrote: >> So you want a spool not a cache. >> Any file in /var/cache can be nuked at any time, that's how /var/cache is >> defined. I won't quote the FHS again, you can read it yourself. > > No I don't want a spool. This isn't spool files. I want to decide when > the cache gets nuked. But you can't. When you write files in /var/cache, you're giving explicit permission to their deletion without notice (by other administrators, cron jobs, other processes, etc). So it's a bit ridiculous to "protect" them from yum clean all afterwards. -- Nicolas Mailhot From jkeating at j2solutions.net Fri Dec 9 17:38:11 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 09 Dec 2005 09:38:11 -0800 Subject: yum clean bug In-Reply-To: <4399BF3E.6040206@laposte.net> References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <4399358A.2060005@laposte.net> <1134141515.3010.34.camel@yoda.loki.me> <28475.192.54.193.25.1134142627.squirrel@rousalka.dyndns.org> <1134143061.3010.41.camel@yoda.loki.me> <4399BF3E.6040206@laposte.net> Message-ID: <1134149891.3010.71.camel@yoda.loki.me> On Fri, 2005-12-09 at 18:30 +0100, Nicolas Mailhot wrote: > > But you can't. When you write files in /var/cache, you're giving > explicit permission to their deletion without notice (by other > administrators, cron jobs, other processes, etc). So it's a bit > ridiculous to "protect" them from yum clean all afterwards. Actually yes I can. I'm reasonably assured that on my systems there are no cron jobs that touch /var/yum/cache for removals, no other admins that are going to touch those files, and no other processes. It is rather silly to expect random process to go willy nilly through /var/cache and remove crap at will. And this is really beside the point. The line was drawn at Yum. Yum will not touch content that is not in an enabled repo. End of discussion. Just because you don't agree doesn't mean we're wrong, and vice/versa. Doesn't really matter who is right/wrong in this case, the only person with the power to change this has made up his mind. He's posted reasons, others have agreed and extrapolated on these reasons. Work arounds have been listed, invitations are out to code around these work arounds into an acceptable location. Why are we still discussing this? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From jkeating at j2solutions.net Fri Dec 9 17:42:17 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 09 Dec 2005 09:42:17 -0800 Subject: yum clean bug In-Reply-To: <4399BE90.7080809@laposte.net> References: <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <4399358A.2060005@laposte.net> <604aa7910512090710q2b72018ao68307cc24eafa3f0@mail.gmail.com> <22905.192.54.193.25.1134142460.squirrel@rousalka.dyndns.org> <1134142976.3010.39.camel@yoda.loki.me> <4399BE90.7080809@laposte.net> Message-ID: <1134150137.3010.75.camel@yoda.loki.me> On Fri, 2005-12-09 at 18:27 +0100, Nicolas Mailhot wrote: > If yum is so concerned about this "data" safety why is it storing it in > a filesystem tree specifically reserved for stuff that can be removed > without notice? > > But anyway this was not my point. I don't see anything in the FHS that says things will come in randomly and remove stuff w/out notice. It says that the data should be re-creatable. The data is re-creatable. What more do you want? All we're doing is drawing a line on what is acceptable for yum to 'guess' the user wants. > >> Guys, > >> if you don't want to listen to others, and have only abuse to offer, don't > >> answer questions at all. Why do you think every single yum thread is > >> degenerating lately ? Every single poster but you is brain-damaged ? > > > > The only 'abuse' I see > > When people take shots at quotes from a neutral text like the FHS, that > shows they're only interested in harassing people that disagree with > Seth, and have nothing to contribute to the discussion itself. > > (I imagine it's as embarrassing for Seth as having an "helpful" friend > yell the sky is green because you're disagreeing with someone who noted > in the course of his argument the sky is blue) > I'm really sorry you view it as this. I don't know what to say that will allow you to see what we're really trying to do, so I won't even try. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From nicolas.mailhot at laposte.net Fri Dec 9 17:50:38 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 09 Dec 2005 18:50:38 +0100 Subject: yum clean bug In-Reply-To: <1134149891.3010.71.camel@yoda.loki.me> References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <4399358A.2060005@laposte.net> <1134141515.3010.34.camel@yoda.loki.me> <28475.192.54.193.25.1134142627.squirrel@rousalka.dyndns.org> <1134143061.3010.41.camel@yoda.loki.me> <4399BF3E.6040206@laposte.net> <1134149891.3010.71.camel@yoda.loki.me> Message-ID: <4399C3EE.8020007@laposte.net> Jesse Keating wrote: > Just because you don't > agree doesn't mean we're wrong, and vice/versa. Just because Seth can choose not to do something does not mean he can redefine /var/cache meaning > Why are we still discussing this? Because you don't want to concede any point, even those on which you're obviously wrong. If you want to be consistent (I won't say right or wrong, just consistent) (re)defining the current contents of /var/cache/yum as data which must be preserved means moving it to /var/spool/yum. Which will actually document the fact you want this data to be persistent, and stop people asking why you're not deleting it when requested. -- Nicolas Mailhot From skvidal at phy.duke.edu Fri Dec 9 17:55:41 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 09 Dec 2005 12:55:41 -0500 Subject: yum clean bug In-Reply-To: <4399C3EE.8020007@laposte.net> References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <4399358A.2060005@laposte.net> <1134141515.3010.34.camel@yoda.loki.me> <28475.192.54.193.25.1134142627.squirrel@rousalka.dyndns.org> <1134143061.3010.41.camel@yoda.loki.me> <4399BF3E.6040206@laposte.net> <1134149891.3010.71.camel@yoda.loki.me> <4399C3EE.8020007@laposte.net> Message-ID: <1134150941.30757.37.camel@cutter> On Fri, 2005-12-09 at 18:50 +0100, Nicolas Mailhot wrote: > Jesse Keating wrote: > > > Just because you don't > > agree doesn't mean we're wrong, and vice/versa. > > Just because Seth can choose not to do something does not mean he can > redefine /var/cache meaning let's be clear - I didn't redefine /var/cache's meaning. I simply chose to be conservative with delete operations in this directory. There's been no redefinition at all. -sv From skvidal at phy.duke.edu Fri Dec 9 18:01:14 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Fri, 09 Dec 2005 13:01:14 -0500 Subject: yum clean bug In-Reply-To: <1134150941.30757.37.camel@cutter> References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <4399358A.2060005@laposte.net> <1134141515.3010.34.camel@yoda.loki.me> <28475.192.54.193.25.1134142627.squirrel@rousalka.dyndns.org> <1134143061.3010.41.camel@yoda.loki.me> <4399BF3E.6040206@laposte.net> <1134149891.3010.71.camel@yoda.loki.me> <4399C3EE.8020007@laposte.net> <1134150941.30757.37.camel@cutter> Message-ID: <1134151274.30757.41.camel@cutter> On Fri, 2005-12-09 at 12:55 -0500, seth vidal wrote: > On Fri, 2005-12-09 at 18:50 +0100, Nicolas Mailhot wrote: > > Jesse Keating wrote: > > > > > Just because you don't > > > agree doesn't mean we're wrong, and vice/versa. > > > > Just because Seth can choose not to do something does not mean he can > > redefine /var/cache meaning > > let's be clear - I didn't redefine /var/cache's meaning. I simply chose > to be conservative with delete operations in this directory. > and as another comment from the FHS: From: http://www.pathname.com/fhs/pub/fhs-2.3.html#VARCACHEAPPLICATIONCACHEDATA Files located under /var/cache may be expired in an application specific manner, by the system administrator, or both. Yum's clean function is the application specific manner is the one I've implemented. In no way have I redefined /var/cache's meaning. I take remarks that I'm violating a standard very seriously and I do not appreciate them being bandied about for histrionic purposes. -sv From nicolas.mailhot at laposte.net Fri Dec 9 18:00:50 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 09 Dec 2005 19:00:50 +0100 Subject: yum clean bug In-Reply-To: <1134150137.3010.75.camel@yoda.loki.me> References: <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <4399358A.2060005@laposte.net> <604aa7910512090710q2b72018ao68307cc24eafa3f0@mail.gmail.com> <22905.192.54.193.25.1134142460.squirrel@rousalka.dyndns.org> <1134142976.3010.39.camel@yoda.loki.me> <4399BE90.7080809@laposte.net> <1134150137.3010.75.camel@yoda.loki.me> Message-ID: <4399C652.9090902@laposte.net> Jesse Keating wrote: > On Fri, 2005-12-09 at 18:27 +0100, Nicolas Mailhot wrote: >> If yum is so concerned about this "data" safety why is it storing it in >> a filesystem tree specifically reserved for stuff that can be removed >> without notice? >> >> But anyway this was not my point. > > I don't see anything in the FHS that says things will come in randomly > and remove stuff w/out notice. " The application must always be able to recover from manual deletion of these files " So other stuff does not need to notify the app that wrote those files before deleting them " (generally because of a disk space shortage) " So when the system / the admin wants to reclaim some disk space, it's / he's allowed to do a find /var/cache -type f -exec -rm -f \{\} \; Actually it goes even farther than this, other stuff don't have to give any particular reason to delete files in /var/cache. Any package may include such a bit in its install scriplets and it'll be perfectly legit. -- Nicolas Mailhot From jkeating at j2solutions.net Fri Dec 9 18:09:48 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 09 Dec 2005 10:09:48 -0800 Subject: yum clean bug In-Reply-To: <4399C652.9090902@laposte.net> References: <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <4399358A.2060005@laposte.net> <604aa7910512090710q2b72018ao68307cc24eafa3f0@mail.gmail.com> <22905.192.54.193.25.1134142460.squirrel@rousalka.dyndns.org> <1134142976.3010.39.camel@yoda.loki.me> <4399BE90.7080809@laposte.net> <1134150137.3010.75.camel@yoda.loki.me> <4399C652.9090902@laposte.net> Message-ID: <1134151788.3010.84.camel@yoda.loki.me> On Fri, 2005-12-09 at 19:00 +0100, Nicolas Mailhot wrote: > " The application must always be able to recover from manual deletion of > these files " Yum can. How is this relevant? > So other stuff does not need to notify the app that wrote those files > before deleting them How can you extrapolate that meaning? Must be able to recover == can delete w/out notification? Some apps will react rather strangely if you delete the cache they're working from in the middle of an operation... > " (generally because of a disk space shortage) " > > So when the system / the admin wants to reclaim some disk space, it's / > he's allowed to do a find /var/cache -type f -exec -rm -f \{\} \; Nothing is stopping the admin from doing this now. Typically the admin should know what the heck they are doing when doing rm -f actions. One would typically not do this whilst yum or some other app is running actively and using the cache. > Actually it goes even farther than this, other stuff don't have to give > any particular reason to delete files in /var/cache. > > Any package may include such a bit in its install scriplets and it'll be > perfectly legit. > And most likely would never ever get distributed with this bit enabled. Wholesale remove of other's cache items is ridiculous and wouldn't get included anywhere. Nowhere in here do I see any argument that states yum should make assumptions on the user's part about when to remove files not associated with an existing/enabled repository. Do you actually have a valid argument for this feature, or are you just making noise? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From nman64 at n-man.com Fri Dec 9 18:19:25 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Fri, 09 Dec 2005 12:19:25 -0600 Subject: yum clean bug In-Reply-To: <4399C652.9090902@laposte.net> References: <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <4399358A.2060005@laposte.net> <604aa7910512090710q2b72018ao68307cc24eafa3f0@mail.gmail.com> <22905.192.54.193.25.1134142460.squirrel@rousalka.dyndns.org> <1134142976.3010.39.camel@yoda.loki.me> <4399BE90.7080809@laposte.net> <1134150137.3010.75.camel@yoda.loki.me> <4399C652.9090902@laposte.net> Message-ID: <4399CAAD.9030404@n-man.com> Nicolas Mailhot wrote: > Jesse Keating wrote: > > On Fri, 2005-12-09 at 18:27 +0100, Nicolas Mailhot wrote: > >> If yum is so concerned about this "data" safety why is it storing it in > >> a filesystem tree specifically reserved for stuff that can be removed > >> without notice? > >> > >> But anyway this was not my point. > > > > I don't see anything in the FHS that says things will come in randomly > > and remove stuff w/out notice. > > " The application must always be able to recover from manual deletion of > these files " > And yum is perfectly capable of continuing operation if all of the contents of that directory are removed. Notice also that 'manually' and 'by other tools' are two very different things. yum can recover either way, but it is not within the defined behavior of /var/cache for other programs to wipe everything. > So other stuff does not need to notify the app that wrote those files > before deleting them > > " (generally because of a disk space shortage) " > > So when the system / the admin wants to reclaim some disk space, it's / > he's allowed to do a find /var/cache -type f -exec -rm -f \{\} \; > Which you are free to do. Personally, I choose not to, and I don't want yum to do it for me. > Actually it goes even farther than this, other stuff don't have to give > any particular reason to delete files in /var/cache. > > Any package may include such a bit in its install scriplets and it'll be > perfectly legit. > > It would not be standard behavior. yum would be expected to operate afterwards, but other tools should not be trying to do this. If I were to discover another program doing this, I would be complaining on its mailing list much like you are whining right now. Aside from your arguments being futile and self-defeating, they're annoying. You have taken the view that you are right and you represent everyone else. That is a flawed point of view. There is obviously a lot of disagreement here, and no change to yum is going to make that go away. You should try to buck up and do something more constructive about it. Improvements to the documentation and a plugin would both be welcomed, and would not be ignored. I can't say the same for any further posts on this thread. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ -- Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From nicolas.mailhot at laposte.net Fri Dec 9 18:27:29 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 09 Dec 2005 19:27:29 +0100 Subject: yum clean bug In-Reply-To: <1134150941.30757.37.camel@cutter> References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <4399358A.2060005@laposte.net> <1134141515.3010.34.camel@yoda.loki.me> <28475.192.54.193.25.1134142627.squirrel@rousalka.dyndns.org> <1134143061.3010.41.camel@yoda.loki.me> <4399BF3E.6040206@laposte.net> <1134149891.3010.71.camel@yoda.loki.me> <4399C3EE.8020007@laposte.net> <1134150941.30757.37.camel@cutter> Message-ID: <4399CC91.2090209@laposte.net> seth vidal wrote: > On Fri, 2005-12-09 at 18:50 +0100, Nicolas Mailhot wrote: >> Jesse Keating wrote: >> >>> Just because you don't >>> agree doesn't mean we're wrong, and vice/versa. >> Just because Seth can choose not to do something does not mean he can >> redefine /var/cache meaning > > let's be clear - I didn't redefine /var/cache's meaning. I simply chose > to be conservative with delete operations in this directory. Right, my apologies, you didn't express an opinion (one way or the other) on this point. I should not have let myself tricked into lumping all the issues in one and you in an uniform "we". Which shows all the stupidity of a binary "we" against "you" approach. -- Nicolas Mailhot From nicolas.mailhot at laposte.net Fri Dec 9 18:39:42 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 09 Dec 2005 19:39:42 +0100 Subject: yum clean bug In-Reply-To: <1134151788.3010.84.camel@yoda.loki.me> References: <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <4399358A.2060005@laposte.net> <604aa7910512090710q2b72018ao68307cc24eafa3f0@mail.gmail.com> <22905.192.54.193.25.1134142460.squirrel@rousalka.dyndns.org> <1134142976.3010.39.camel@yoda.loki.me> <4399BE90.7080809@laposte.net> <1134150137.3010.75.camel@yoda.loki.me> <4399C652.9090902@laposte.net> <1134151788.3010.84.camel@yoda.loki.me> Message-ID: <4399CF6E.6010906@laposte.net> Jesse Keating wrote: > Nowhere in here do I see any argument that states yum should make > assumptions on the user's part about when to remove files not associated > with an existing/enabled repository. Do you actually have a valid > argument for this feature, or are you just making noise? Do you actually read the messages you're responding to ? This particular subthread had nothing to say on the subject, just that if preserving yum "cache" data presents some interest (because of some particular use cases) /var/cache was a particularly dangerous place to put it. I know Seth well enough to stop arguing when he writes no, never. Since he insists /var/cache/yum/* must be preserved, I was pointing out /var/spool/yum/ would make his choice more clear and consistent with general system rules. -- Nicolas Mailhot From jkeating at j2solutions.net Fri Dec 9 18:55:30 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 09 Dec 2005 10:55:30 -0800 Subject: /var/cache yum usage (was Re: yum clean bug) In-Reply-To: <4399CF6E.6010906@laposte.net> References: <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <4399358A.2060005@laposte.net> <604aa7910512090710q2b72018ao68307cc24eafa3f0@mail.gmail.com> <22905.192.54.193.25.1134142460.squirrel@rousalka.dyndns.org> <1134142976.3010.39.camel@yoda.loki.me> <4399BE90.7080809@laposte.net> <1134150137.3010.75.camel@yoda.loki.me> <4399C652.9090902@laposte.net> <1134151788.3010.84.camel@yoda.loki.me> <4399CF6E.6010906@laposte.net> Message-ID: <1134154530.3010.103.camel@yoda.loki.me> On Fri, 2005-12-09 at 19:39 +0100, Nicolas Mailhot wrote: > Do you actually read the messages you're responding to ? Yes, I do. However it is sometimes difficult to context switch to the exact particular phrase of a message that you might object to. > This particular subthread had nothing to say on the subject, Then why does it exist, and exist w/out a subject change? > just that > if preserving yum "cache" data presents some interest (because of some > particular use cases) /var/cache was a particularly dangerous place to > put it. > > I know Seth well enough to stop arguing when he writes no, never. > > Since he insists /var/cache/yum/* must be preserved, I was pointing out > /var/spool/yum/ would make his choice more clear and consistent with > general system rules. And you missed the entire point. Seth and co are NOT saying that the cache MUST be preserved. We're saying that yum will not be the device that will guess as to when the user might want that cache removed. Please do get the argument right. The argument is whether or not yum should clean this cache out. One camp says that yum itself should only deal w/ cache cleaning of existing/enabled repos. Valid reasons for this have been listed. The other camp indicates that they wish yum to clean all cache that exists within /var/cache/yum. They were told no by Seth, alternatives arose, definitions of the 'all' in yum clean all were extolled, and suggests were made to amend the docs and toss code at yum-utils (to script rm -rf /var/cache/yum/ which is silly IMHO to script this). Since you don't seem to be arguing one camp or the other, you must be out in camp C that is happily telling everybody that what they are saying is wrong, and everything should change because you feel it should. Am I in the right context now? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From jspaleta at gmail.com Fri Dec 9 19:00:02 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 9 Dec 2005 14:00:02 -0500 Subject: yum clean bug In-Reply-To: <4399CF6E.6010906@laposte.net> References: <4399358A.2060005@laposte.net> <604aa7910512090710q2b72018ao68307cc24eafa3f0@mail.gmail.com> <22905.192.54.193.25.1134142460.squirrel@rousalka.dyndns.org> <1134142976.3010.39.camel@yoda.loki.me> <4399BE90.7080809@laposte.net> <1134150137.3010.75.camel@yoda.loki.me> <4399C652.9090902@laposte.net> <1134151788.3010.84.camel@yoda.loki.me> <4399CF6E.6010906@laposte.net> Message-ID: <604aa7910512091100r5df30972w2092a9385a30fdc4@mail.gmail.com> On 12/9/05, Nicolas Mailhot wrote: > Since he insists /var/cache/yum/* must be preserved, I was pointing out > /var/spool/yum/ would make his choice more clear and consistent with > general system rules. I'm pretty sure he didn't say it "must be preserved". Please can you reference the post where he said "must be preserved." My email cache of this thread so far only has you saying anything about "must be preserved." My interpretations of Seth's posts in this discussion is vastly different. Maybe if this conversation were in Esperanto we'd be able to avoid all the confusion from trying to communicate in English. -jef From nicolas.mailhot at laposte.net Fri Dec 9 19:14:36 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 09 Dec 2005 20:14:36 +0100 Subject: yum clean bug In-Reply-To: <604aa7910512091100r5df30972w2092a9385a30fdc4@mail.gmail.com> References: <4399358A.2060005@laposte.net> <604aa7910512090710q2b72018ao68307cc24eafa3f0@mail.gmail.com> <22905.192.54.193.25.1134142460.squirrel@rousalka.dyndns.org> <1134142976.3010.39.camel@yoda.loki.me> <4399BE90.7080809@laposte.net> <1134150137.3010.75.camel@yoda.loki.me> <4399C652.9090902@laposte.net> <1134151788.3010.84.camel@yoda.loki.me> <4399CF6E.6010906@laposte.net> <604aa7910512091100r5df30972w2092a9385a30fdc4@mail.gmail.com> Message-ID: <4399D79C.208@laposte.net> Jeff Spaleta wrote: > On 12/9/05, Nicolas Mailhot wrote: >> Since he insists /var/cache/yum/* must be preserved, I was pointing out >> /var/spool/yum/ would make his choice more clear and consistent with >> general system rules. > > I'm pretty sure he didn't say it "must be preserved". Please can you > reference the post where he said "must be preserved." My email cache > of this thread so far only has you saying anything about "must be > preserved." "But how can I really be sure that ALL the data in that dir is disposable, especially if the user has disabled the repo in question in their config. I err on the side of protecting data. If yum is not told to remove it, then it won't remove it." So this is not-disposable data needing protection. I translate this into data that must be preserved. If it's not preserved it's not really protected, right ? -- Nicolas Mailhot From jkeating at j2solutions.net Fri Dec 9 19:22:14 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 09 Dec 2005 11:22:14 -0800 Subject: yum clean bug In-Reply-To: <4399D79C.208@laposte.net> References: <4399358A.2060005@laposte.net> <604aa7910512090710q2b72018ao68307cc24eafa3f0@mail.gmail.com> <22905.192.54.193.25.1134142460.squirrel@rousalka.dyndns.org> <1134142976.3010.39.camel@yoda.loki.me> <4399BE90.7080809@laposte.net> <1134150137.3010.75.camel@yoda.loki.me> <4399C652.9090902@laposte.net> <1134151788.3010.84.camel@yoda.loki.me> <4399CF6E.6010906@laposte.net> <604aa7910512091100r5df30972w2092a9385a30fdc4@mail.gmail.com> <4399D79C.208@laposte.net> Message-ID: <1134156134.3010.117.camel@yoda.loki.me> On Fri, 2005-12-09 at 20:14 +0100, Nicolas Mailhot wrote: > "But how can I really be sure that ALL the data in that dir is > disposable, especially if the user has disabled the repo in question in > their config. > > I err on the side of protecting data. If yum is not told to remove it, > then it won't remove it." > > So this is not-disposable data needing protection. I translate this into > data that must be preserved. If it's not preserved it's not really > protected, right ? You're extrapolating. The data can/could be recreated. The user may not wish to incur the cost of the recreation. Lots of bandwidth, lots of time, etc... Thus Seth is developing his program to err on the side of conservation rather than whole sale cache removal. Nothing in his reasoning says that the data HAS to remain. The user may wish it to remain. Cache does you no good if you just remove it every single time it gets written. Theoretically you can do this, because of hte way that cache works, and how the FHS says that cache should work. However a lot of times this isn't a desirable usage. Again you are taking words and meanings and morphing them into a position you feel you could argue against, for apparently no good reason. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From n0dalus+redhat at gmail.com Fri Dec 9 19:28:09 2005 From: n0dalus+redhat at gmail.com (n0dalus) Date: Sat, 10 Dec 2005 05:58:09 +1030 Subject: yum clean bug In-Reply-To: <1134156134.3010.117.camel@yoda.loki.me> References: <1134142976.3010.39.camel@yoda.loki.me> <4399BE90.7080809@laposte.net> <1134150137.3010.75.camel@yoda.loki.me> <4399C652.9090902@laposte.net> <1134151788.3010.84.camel@yoda.loki.me> <4399CF6E.6010906@laposte.net> <604aa7910512091100r5df30972w2092a9385a30fdc4@mail.gmail.com> <4399D79C.208@laposte.net> <1134156134.3010.117.camel@yoda.loki.me> Message-ID: <6280325c0512091128j685c5553h59b33a23116472af@mail.gmail.com> On 12/10/05, Jesse Keating wrote: > On Fri, 2005-12-09 at 20:14 +0100, Nicolas Mailhot wrote: > > "But how can I really be sure that ALL the data in that dir is > > disposable, especially if the user has disabled the repo in question in > > their config. > > > > I err on the side of protecting data. If yum is not told to remove it, > > then it won't remove it." > > > > So this is not-disposable data needing protection. I translate this into > > data that must be preserved. If it's not preserved it's not really > > protected, right ? > > You're extrapolating. The data can/could be recreated. The user may > not wish to incur the cost of the recreation. Lots of bandwidth, lots > of time, etc... Thus Seth is developing his program to err on the side > of conservation rather than whole sale cache removal. Nothing in his > reasoning says that the data HAS to remain. The user may wish it to > remain. Cache does you no good if you just remove it every single time > it gets written. Theoretically you can do this, because of hte way that > cache works, and how the FHS says that cache should work. However a lot > of times this isn't a desirable usage. > > Again you are taking words and meanings and morphing them into a > position you feel you could argue against, for apparently no good > reason. > Correct me if I'm wrong, but if the user doesn't want to incur the cost of recreation, they shouldn't be running `yum clean all`. It's perfectly reasonable to assume that there will be such a cost associated with it. If the user wishes it to remain, they shouldn't really be running any clean commands. The program is erring on the side of conservation when it is explicitly told to 'clean all'. n0dalus. From jspaleta at gmail.com Fri Dec 9 19:34:13 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 9 Dec 2005 14:34:13 -0500 Subject: yum clean bug In-Reply-To: <4399D79C.208@laposte.net> References: <22905.192.54.193.25.1134142460.squirrel@rousalka.dyndns.org> <1134142976.3010.39.camel@yoda.loki.me> <4399BE90.7080809@laposte.net> <1134150137.3010.75.camel@yoda.loki.me> <4399C652.9090902@laposte.net> <1134151788.3010.84.camel@yoda.loki.me> <4399CF6E.6010906@laposte.net> <604aa7910512091100r5df30972w2092a9385a30fdc4@mail.gmail.com> <4399D79C.208@laposte.net> Message-ID: <604aa7910512091134j6ccaf0aeia4810633781e9e06@mail.gmail.com> On 12/9/05, Nicolas Mailhot wrote: > So this is not-disposable data needing protection. I translate this into > data that must be preserved. If it's not preserved it's not really > protected, right ? More evidence that communicating in English is inherently prone to miscommunication. Disposable and re-generatable are not perfectly equivalent concepts. While by definition data in the cache filesystem can be re-generated when needed for tool operation, nothing says it preferable to re-generate if it can be avoided. Yum's clean policy is coded to avoid unnecessary re-generation. In fact, because cached items are defined to be resource intensive to generate in the FHS definition for /var/cache ... i think that automatically implies that well coded tools treat the cache conservatively when removals are done to avoid wasteful calculation or i/o when re-generating cache later that could have been avoided. Its the difference between doing something just because the action is strictly allowed and refraining from doing something to avoid doing more unncessary work later to re-generate time or i/o intensive cache when it can be avoided. -jef From jkeating at j2solutions.net Fri Dec 9 19:38:51 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 09 Dec 2005 11:38:51 -0800 Subject: yum clean bug In-Reply-To: <6280325c0512091128j685c5553h59b33a23116472af@mail.gmail.com> References: <1134142976.3010.39.camel@yoda.loki.me> <4399BE90.7080809@laposte.net> <1134150137.3010.75.camel@yoda.loki.me> <4399C652.9090902@laposte.net> <1134151788.3010.84.camel@yoda.loki.me> <4399CF6E.6010906@laposte.net> <604aa7910512091100r5df30972w2092a9385a30fdc4@mail.gmail.com> <4399D79C.208@laposte.net> <1134156134.3010.117.camel@yoda.loki.me> <6280325c0512091128j685c5553h59b33a23116472af@mail.gmail.com> Message-ID: <1134157131.3010.119.camel@yoda.loki.me> On Sat, 2005-12-10 at 05:58 +1030, n0dalus wrote: > Correct me if I'm wrong, but if the user doesn't want to incur the > cost of recreation, they shouldn't be running `yum clean all`. It's > perfectly reasonable to assume that there will be such a cost > associated with it. If the user wishes it to remain, they shouldn't > really be running any clean commands. The program is erring on the > side of conservation when it is explicitly told to 'clean all'. The all refers to the packages, repodata, repmod, etc.. for enabled repos. Yum would be doing guess work if it touched disabled/missing repo datas. This is where yum won't go, into this guess work. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From n0dalus+redhat at gmail.com Fri Dec 9 19:55:01 2005 From: n0dalus+redhat at gmail.com (n0dalus) Date: Sat, 10 Dec 2005 06:25:01 +1030 Subject: yum clean bug In-Reply-To: <1134157131.3010.119.camel@yoda.loki.me> References: <1134150137.3010.75.camel@yoda.loki.me> <4399C652.9090902@laposte.net> <1134151788.3010.84.camel@yoda.loki.me> <4399CF6E.6010906@laposte.net> <604aa7910512091100r5df30972w2092a9385a30fdc4@mail.gmail.com> <4399D79C.208@laposte.net> <1134156134.3010.117.camel@yoda.loki.me> <6280325c0512091128j685c5553h59b33a23116472af@mail.gmail.com> <1134157131.3010.119.camel@yoda.loki.me> Message-ID: <6280325c0512091155q70c8949ci7b68587b2b36ea0a@mail.gmail.com> On 12/10/05, Jesse Keating wrote: > > The all refers to the packages, repodata, repmod, etc.. for enabled > repos. Yum would be doing guess work if it touched disabled/missing > repo datas. This is where yum won't go, into this guess work. > For that matter, why should `yum clean packages` only clean packages in enabled repos? The entire conversation could apply equally to all the clean sub-commands. Just saying that 'all' is the combination of all the other clean commands doesn't actually change the discussion in any meaninful way. Yum is doing just as much guess work by assuming the user doesn't want disabled/removed repos to be cleaned. It has already been concluded in the leading discussion that 'all' is simply an ambiguous word in this case and that the documentation might benefit from improvements reflecting this. n0dalus. From jkeating at j2solutions.net Fri Dec 9 20:01:40 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 09 Dec 2005 12:01:40 -0800 Subject: yum clean bug In-Reply-To: <6280325c0512091155q70c8949ci7b68587b2b36ea0a@mail.gmail.com> References: <1134150137.3010.75.camel@yoda.loki.me> <4399C652.9090902@laposte.net> <1134151788.3010.84.camel@yoda.loki.me> <4399CF6E.6010906@laposte.net> <604aa7910512091100r5df30972w2092a9385a30fdc4@mail.gmail.com> <4399D79C.208@laposte.net> <1134156134.3010.117.camel@yoda.loki.me> <6280325c0512091128j685c5553h59b33a23116472af@mail.gmail.com> <1134157131.3010.119.camel@yoda.loki.me> <6280325c0512091155q70c8949ci7b68587b2b36ea0a@mail.gmail.com> Message-ID: <1134158500.3010.126.camel@yoda.loki.me> On Sat, 2005-12-10 at 06:25 +1030, n0dalus wrote: > For that matter, why should `yum clean packages` only clean packages > in enabled repos? The entire conversation could apply equally to all > the clean sub-commands. Just saying that 'all' is the combination of > all the other clean commands doesn't actually change the discussion in > any meaninful way. > > Yum is doing just as much guess work by assuming the user doesn't want > disabled/removed repos to be cleaned. It has already been concluded in > the leading discussion that 'all' is simply an ambiguous word in this > case and that the documentation might benefit from improvements > reflecting this. You are correct. Yum is guessing and guessing is prone to error. But, since we are prone to error, we're going to error on the safe side, and go after the enabled repos, rather than everything. This is the safer option. This is the way it works. Absolutely nobody is stopping you from submitting patches for the documentations. Seth has said nothing wrt to this. Instead of discussing this indefinitely, do something productive? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From nicolas.mailhot at laposte.net Fri Dec 9 20:10:16 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 09 Dec 2005 21:10:16 +0100 Subject: yum clean bug In-Reply-To: <604aa7910512091134j6ccaf0aeia4810633781e9e06@mail.gmail.com> References: <22905.192.54.193.25.1134142460.squirrel@rousalka.dyndns.org> <1134142976.3010.39.camel@yoda.loki.me> <4399BE90.7080809@laposte.net> <1134150137.3010.75.camel@yoda.loki.me> <4399C652.9090902@laposte.net> <1134151788.3010.84.camel@yoda.loki.me> <4399CF6E.6010906@laposte.net> <604aa7910512091100r5df30972w2092a9385a30fdc4@mail.gmail.com> <4399D79C.208@laposte.net> <604aa7910512091134j6ccaf0aeia4810633781e9e06@mail.gmail.com> Message-ID: <4399E4A8.5060201@laposte.net> Jeff Spaleta wrote: > On 12/9/05, Nicolas Mailhot wrote: >> So this is not-disposable data needing protection. I translate this into >> data that must be preserved. If it's not preserved it's not really >> protected, right ? > > More evidence that communicating in English is inherently prone to > miscommunication. > > Disposable and re-generatable are not perfectly equivalent concepts. > While by definition data in the cache filesystem can be re-generated > when needed for tool operation, nothing says it preferable to > re-generate if it can be avoided. Yum's clean policy is coded to > avoid unnecessary re-generation. > > In fact, because cached items are defined to be resource intensive to > generate in the FHS definition for /var/cache ... i think that > automatically implies that well coded tools treat the cache > conservatively when removals are done to avoid wasteful calculation or > i/o when re-generating cache later that could have been avoided. Its > the difference between doing something just because the action is > strictly allowed and refraining from doing something to avoid doing > more unncessary work later to re-generate time or i/o intensive cache > when it can be avoided. Ok. So we're back to the cache aspects, and you agree these is no mysterious data needing to be preserved in /var/cache/yum, only standard cache files. 1. shouldn't yum remove every part of /var/cache/yum not covered by a repo (enabled or not) since obviously it can not use it for optimization purposes ? (this would correspond to standard home-keeping after repo removal/renaming). Other tools routinely remove this kind of leftovers or at least flag them (yum leftovers can be huge, a repo can consume hundreds of MiBs in old downloaded packages, and people seem to like renaming repositories). Unless there is some other reason to keep it ? (but then it does not belong in /var/cache/yum anymore) 2. couldn't the user be allowed to easily purge the cache (and no enablerepo=* does not count as easily, especially considering Seth finds rpm flags "cryptic"?) ? Even Mozilla/Firefox/etc allow this, and they have to manage users that would never approach the command line let alone yum Remember, this is yum's private repository, only yum writes in it (the FHS allows nuking the cache of someone else not messing in any other way with it), and the data inside can be re-generated when needed (your words) And this was my whole argument, apologies to all the people who got it twenty messages before. ? Or whatever the exact term he used last time, I don't remember it exactly -- Nicolas Mailhot From jkeating at j2solutions.net Fri Dec 9 20:29:29 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 09 Dec 2005 12:29:29 -0800 Subject: yum clean bug In-Reply-To: <4399E4A8.5060201@laposte.net> References: <22905.192.54.193.25.1134142460.squirrel@rousalka.dyndns.org> <1134142976.3010.39.camel@yoda.loki.me> <4399BE90.7080809@laposte.net> <1134150137.3010.75.camel@yoda.loki.me> <4399C652.9090902@laposte.net> <1134151788.3010.84.camel@yoda.loki.me> <4399CF6E.6010906@laposte.net> <604aa7910512091100r5df30972w2092a9385a30fdc4@mail.gmail.com> <4399D79C.208@laposte.net> <604aa7910512091134j6ccaf0aeia4810633781e9e06@mail.gmail.com> <4399E4A8.5060201@laposte.net> Message-ID: <1134160169.3010.143.camel@yoda.loki.me> On Fri, 2005-12-09 at 21:10 +0100, Nicolas Mailhot wrote: > 1. shouldn't yum remove every part of /var/cache/yum not covered by a > repo (enabled or not) since obviously it can not use it for optimization > purposes ? No. Just because the current run of yum isn't using it doesn't mean that the next run of yum would. Again it is guessing as to why the repo isn't there anymore, something that Seth has indicated that he does not want to delete on. Err on the side of data protection. This is a very simple standard, should be easy to understand. > (this would correspond to standard home-keeping after repo > removal/renaming). Other tools routinely remove this kind of leftovers > or at least flag them (yum leftovers can be huge, a repo can consume > hundreds of MiBs in old downloaded packages, and people seem to like > renaming repositories). Unless there is some other reason to keep it ? > (but then it does not belong in /var/cache/yum anymore) Yum doesn't know for sure what the user wants to do with this. Rather than delete it out from under the user, we let the user decide when to clean it out, with an rm -f. You seem to be stuck a bit upon the idea of /var/cache. Just because the data _can_ be deleted doesn't mean it _should_ be deleted. Or just because the user may want to keep it around for a bit doesn't mean that it automatically has to be moved out of /var/cache. Cache timeouts, verifications, etc.. these are actions that other applications use to determine when/if to dump the cache. If an application decides that it would like the cache to stick around, does that mean it has to go into /var/spool? No. Please understand that just because the user may wish the cache to stick around doesn't mean that it has to move out of /var/cache. > 2. couldn't the user be allowed to easily purge the cache (and no > enablerepo=* does not count as easily, especially considering Seth finds > rpm flags "cryptic"?) ? rm -rf /var/cache/yum/* That does a clean all all. (clean all the cache components from all the repositories ever known to yum). > Even Mozilla/Firefox/etc allow this, and they > have to manage users that would never approach the command line let > alone yum You're comparing a graphical application to yum for ease of use? Come on... Go make this suggestion to whatever gui yum frontend you like. They can do an rm -rf of the cache dir if they want. Yum will recreate it. The users can complain if this frontend does things they don't like. > Remember, this is yum's private repository, only yum writes in it (the > FHS allows nuking the cache of someone else not messing in any other way > with it), and the data inside can be re-generated when needed (your words) Just because it is allowed does not mean it is a good practice. Unless there is really really really good reasons, applications don't futz w/ the caches of other applications. Especially because nuking cache WHILE the application is using it can lead to unexpected difficulties. Now a utility or a front end can nuke the cache for yum, however it then becomes the responsibility of that utility or front end to make the assumptions on the user's behalf. Yum itself will always err on the side of data protection. Don't remove it unless explicitly told to w/ enable repo, or if the admin removes it by hand. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From jspaleta at gmail.com Fri Dec 9 20:30:09 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 9 Dec 2005 15:30:09 -0500 Subject: yum clean bug In-Reply-To: <4399E4A8.5060201@laposte.net> References: <4399BE90.7080809@laposte.net> <1134150137.3010.75.camel@yoda.loki.me> <4399C652.9090902@laposte.net> <1134151788.3010.84.camel@yoda.loki.me> <4399CF6E.6010906@laposte.net> <604aa7910512091100r5df30972w2092a9385a30fdc4@mail.gmail.com> <4399D79C.208@laposte.net> <604aa7910512091134j6ccaf0aeia4810633781e9e06@mail.gmail.com> <4399E4A8.5060201@laposte.net> Message-ID: <604aa7910512091230m4cd2e490p79e8c46b784eb89b@mail.gmail.com> On 12/9/05, Nicolas Mailhot wrote: > 1. shouldn't yum remove every part of /var/cache/yum not covered by a > repo (enabled or not) since obviously it can not use it for optimization > purposes ? (this would correspond to standard home-keeping after repo > removal/renaming). Shrug... or is this the job of the mechanism that removes or renames? Other tools routinely remove this kind of leftovers > or at least flag them specific examples of tools that do this? > 2. couldn't the user be allowed to easily purge the cache (and no > enablerepo=* does not count as easily, especially considering Seth finds > rpm flags "cryptic"?) ? Even Mozilla/Firefox/etc allow this, and they > have to manage users that would never approach the command line let > alone yum if yum were a gui application... i could see an argument for exposing better UI for sanitize functions. But since yum isn't a gui... there isn't a lot of choices on how to expose "easier" ui. Cmdline tools expose options via cmdline switches. Mozilla has ui exposed to remove the .mozilla directory completely? > Remember, this is yum's private repository, only yum writes in it only yum writes to it? Can you be "sure" of that? I didn't realize that the FHS mandated that a single application writes to its associated /var/cache/ subdirectory and that all other applications leave that directory alone. In fact I've think you have argued the opposite already. Just because yum could nuke the whole tree on every operation.. does not mean that is the best way to use the cache resources which have already been generated. Just because there is data in the directory tree that yum doesn't map to a configured repository doesn't mean its not cache that is useful for some other tool. -jef" We are the users We are the local admins We are the ones with i/o and cpu constrains So let's start caching It's a choice we're making we're saving our old cache its true it makes a less i/o and cpu intensive day for you and me... "spaleta From ed at eh3.com Sat Dec 10 00:04:24 2005 From: ed at eh3.com (Ed Hill) Date: Fri, 09 Dec 2005 19:04:24 -0500 Subject: g77/gfortran incompatibilities In-Reply-To: <20051209164454.GA7447@free.fr> References: <20051209164454.GA7447@free.fr> Message-ID: <1134173064.2522.142.camel@ernie> On Fri, 2005-12-09 at 17:44 +0100, Patrice Dumas wrote: > Hello, > > I am currently annoyed by the gfortran/g77 incompatibilities. Indeed gfortran > has still some regressions with regard with g77, especially some missing > intrinsics. Some are listed in the g77 regressions meta-bug here: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292 > some are not listed (getarg, imag). > > So there is still a need for g77 to build some code (for example the cernlib > in fedora extras). Now the trouble is that code compiled with g77 and > gfortran are not binary compatible. I have been told that compiling using > g77 with -fno-f2c leads to compatibility with gfortran. Is it the case? > > If it is the case, I think that all the libraries compiled with g77 in > fedora extras (is there any fortran in fedora core?) should be compiled > with -fno-f2c with the issue that all the code to be compiled against > those libraries should also be compiled with -fno-f2c. Does this make sense? Hi Patrice, Thanks for pointing this out! I was aware of the incompatible name- mangling between g77 and gfortran but wasn't aware of the -fno-f2c flag. It does sound like a good idea provided the code generated on either end really is compatible. Could one of the Fedora compiler gurus please step in and say whether this is a good idea or not? Also, for the netcdf-devel package, I've been providing two sets of libs: one compiled with g77 and one with gfortran. I realize that its a bit of an annoyance for a packager but I was trying to do everything I could to make it easy for end users who might still be stuck on g77 for various reasons. Ed -- Edward H. Hill III, PhD office: MIT Dept. of EAPS; Rm 54-1424; 77 Massachusetts Ave. Cambridge, MA 02139-4307 emails: eh3 at mit.edu ed at eh3.com URLs: http://web.mit.edu/eh3/ http://eh3.com/ phone: 617-253-0098 fax: 617-253-4464 From pmatilai at laiskiainen.org Sat Dec 10 05:21:01 2005 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Fri, 9 Dec 2005 21:21:01 -0800 (PST) Subject: yum clean bug In-Reply-To: <1134158500.3010.126.camel@yoda.loki.me> References: <1134150137.3010.75.camel@yoda.loki.me> <4399C652.9090902@laposte.net> <1134151788.3010.84.camel@yoda.loki.me> <4399CF6E.6010906@laposte.net> <604aa7910512091100r5df30972w2092a9385a30fdc4@mail.gmail.com> <4399D79C.208@laposte.net> <1134156134.3010.117.camel@yoda.loki.me> <6280325c0512091128j685c5553h59b33a23116472af@mail.gmail.com> <1134157131.3010.119.camel@yoda.loki.me> <6280325c0512091155q70c8949ci7b68587b2b36ea0a@mail.gmail.com> <1134158500.3010.126.camel@yoda.loki.me> Message-ID: On Fri, 9 Dec 2005, Jesse Keating wrote: > On Sat, 2005-12-10 at 06:25 +1030, n0dalus wrote: >> For that matter, why should `yum clean packages` only clean packages >> in enabled repos? The entire conversation could apply equally to all >> the clean sub-commands. Just saying that 'all' is the combination of >> all the other clean commands doesn't actually change the discussion in >> any meaninful way. >> >> Yum is doing just as much guess work by assuming the user doesn't want >> disabled/removed repos to be cleaned. It has already been concluded in >> the leading discussion that 'all' is simply an ambiguous word in this >> case and that the documentation might benefit from improvements >> reflecting this. > > You are correct. Yum is guessing and guessing is prone to error. But, > since we are prone to error, we're going to error on the safe side, and > go after the enabled repos, rather than everything. This is the safer > option. This is the way it works. Well, yum is not guessing (if a depsolver started *guessing* stuff we'd all have pretty .. um, "interesting" systems at our hands ;), it's behaving in a perfectly constant way, but not the way some of us expect. And in fact it IS behaving contrary to the documentation: yum clean packages Eliminate any cached packages from the system. Note that pack ages are not automatically deleted after they are downloaded. The wording "eliminate any cached packages" doesn't leave anything to guesswork IMHO. > Absolutely nobody is stopping you from submitting patches for the > documentations. Seth has said nothing wrt to this. Instead of > discussing this indefinitely, do something productive? Well, Seth has spoken on the topic and it seems that people have actually found uses for this behavior. I'll update the manpage to refer to the fact that the clean operations only operate on enabled repositories, end of story, ok? Before this thread gets any more ridiculous than it already is... - Panu - From nicolas.mailhot at laposte.net Sat Dec 10 08:02:11 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 10 Dec 2005 09:02:11 +0100 Subject: yum clean bug In-Reply-To: <604aa7910512091230m4cd2e490p79e8c46b784eb89b@mail.gmail.com> References: <4399BE90.7080809@laposte.net> <1134150137.3010.75.camel@yoda.loki.me> <4399C652.9090902@laposte.net> <1134151788.3010.84.camel@yoda.loki.me> <4399CF6E.6010906@laposte.net> <604aa7910512091100r5df30972w2092a9385a30fdc4@mail.gmail.com> <4399D79C.208@laposte.net> <604aa7910512091134j6ccaf0aeia4810633781e9e06@mail.gmail.com> <4399E4A8.5060201@laposte.net> <604aa7910512091230m4cd2e490p79e8c46b784eb89b@mail.gmail.com> Message-ID: <439A8B83.8060208@laposte.net> Jeff Spaleta wrote: > On 12/9/05, Nicolas Mailhot wrote: >> 1. shouldn't yum remove every part of /var/cache/yum not covered by a >> repo (enabled or not) since obviously it can not use it for optimization >> purposes ? (this would correspond to standard home-keeping after repo >> removal/renaming). > Shrug... or is this the job of the mechanism that removes or renames? > > Other tools routinely remove this kind of leftovers >> or at least flag them > > specific examples of tools that do this? OO.o will remove crash dumps after restart amanda will list any file in its backup queue it does not expect (either previous runs leftovers or files someone else dumped there) >> 2. couldn't the user be allowed to easily purge the cache (and no >> enablerepo=* does not count as easily, especially considering Seth finds >> rpm flags "cryptic"?) ? Even Mozilla/Firefox/etc allow this, and they >> have to manage users that would never approach the command line let >> alone yum > > if yum were a gui application... i could see an argument for exposing > better UI for sanitize functions. But since yum isn't a gui... there > isn't a lot of choices on how to expose "easier" ui. Cmdline tools > expose options via cmdline switches. > > Mozilla has ui exposed to remove the .mozilla directory completely? Mozilla has ui exposed to remove its cache completely. No one is talking about removing /etc/yum.* completely (which would correspond to your .mozilla example) >> Remember, this is yum's private repository, only yum writes in it > only yum writes to it? Can you be "sure" of that? I didn't realize > that the FHS mandated that a single application writes to its > associated /var/cache/ subdirectory > and that all other applications leave that directory alone. In fact > I've think you have argued the opposite already. Nah, I've argued other apps could remove its contents not that they could write there. Read the spec again, nowhere is writing mentioned > Just because yum could nuke the whole tree on every operation.. does > not mean that is the best way to use the cache resources which have > already been generated. Who asked for nuking the whole tree on every operation ? > Just because there is data in the directory > tree that yum doesn't map to a configured repository doesn't mean its > not cache that is useful for some other tool. Which tool ? With what justification ? Since I've been asked to justify every assertion I used, could you consider stopping the handwaving please ? -- Nicolas Mailhot From nicolas.mailhot at laposte.net Sat Dec 10 08:17:01 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 10 Dec 2005 09:17:01 +0100 Subject: yum clean bug In-Reply-To: <1134160169.3010.143.camel@yoda.loki.me> References: <22905.192.54.193.25.1134142460.squirrel@rousalka.dyndns.org> <1134142976.3010.39.camel@yoda.loki.me> <4399BE90.7080809@laposte.net> <1134150137.3010.75.camel@yoda.loki.me> <4399C652.9090902@laposte.net> <1134151788.3010.84.camel@yoda.loki.me> <4399CF6E.6010906@laposte.net> <604aa7910512091100r5df30972w2092a9385a30fdc4@mail.gmail.com> <4399D79C.208@laposte.net> <604aa7910512091134j6ccaf0aeia4810633781e9e06@mail.gmail.com> <4399E4A8.5060201@laposte.net> <1134160169.3010.143.camel@yoda.loki.me> Message-ID: <439A8EFD.4050708@laposte.net> Jesse Keating wrote: > rm -rf /var/cache/yum/* "I don't want to manage the data I wrote in my own directory, especially the data I forgot about. I'm forcing users to do # rpm -fr /... afterwards, with all the associated risks but that's too bad I'm considering any associated accident not my fault(TM)" This seems the alpha and omega of your argument, when not cloaked in all sorts of lofty justifications that make people angry because they can see them for what they are. -- Nicolas Mailhot From skvidal at phy.duke.edu Sat Dec 10 08:37:54 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Sat, 10 Dec 2005 03:37:54 -0500 Subject: yum clean bug In-Reply-To: References: <1134150137.3010.75.camel@yoda.loki.me> <4399C652.9090902@laposte.net> <1134151788.3010.84.camel@yoda.loki.me> <4399CF6E.6010906@laposte.net> <604aa7910512091100r5df30972w2092a9385a30fdc4@mail.gmail.com> <4399D79C.208@laposte.net> <1134156134.3010.117.camel@yoda.loki.me> <6280325c0512091128j685c5553h59b33a23116472af@mail.gmail.com> <1134157131.3010.119.camel@yoda.loki.me> <6280325c0512091155q70c8949ci7b68587b2b36ea0a@mail.gmail.com> <1134158500.3010.126.camel@yoda.loki.me> Message-ID: <1134203874.2183.40.camel@cutter> > Well, Seth has spoken on the topic and it seems that people have actually > found uses for this behavior. I'll update the manpage to refer to the fact > that the clean operations only operate on enabled repositories, end of > story, ok? Before this thread gets any more ridiculous than it already > is... How about we just say that all yum operations will only act on enabled repositories? Just so there is no doubt that disabled repos are not acted on. -sv From buildsys at redhat.com Sat Dec 10 11:11:12 2005 From: buildsys at redhat.com (Build System) Date: Sat, 10 Dec 2005 06:11:12 -0500 Subject: rawhide report: 20051210 changes Message-ID: <200512101111.jBABBCZH027063@porkchop.devel.redhat.com> Removed package anaconda-help Updated Packages: alsa-lib-1.0.10rf-3 ------------------- * Fri Dec 09 2005 Martin Stransky 1.0.10rf-3 - rights for shared memory have been moved to config files amtu-1.0.4-1 ------------ * Fri Dec 09 2005 Steve Grubb 1.0.4-1 - New upstream version updated for new audit messages ant-0:1.6.5-1jpp_1fc -------------------- * Fri Dec 09 2005 Jesse Keating - 0:1.6.5-1jpp_1fc - rebuild for gcc-4.1.0-0.6 * Tue Nov 08 2005 Vadim Nasardinov - 0:1.6.5-0jpp_1fc - Converted from ISO-8859-1 to UTF-8. (The correct encoding was somehow lost in going from version 1.58 to 1.59.) apr-1.2.2-5.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt * Fri Dec 09 2005 Joe Orton 1.2.2-5 - rebuild for new gcc * Thu Dec 08 2005 Joe Orton 1.2.2-4 - add apr_file_seek() fixes from upstream (r326593, r326597) apr-util-1.2.2-2.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt audiofile-1:0.2.6-2.1 --------------------- * Fri Dec 09 2005 Jesse Keating - 0.2.6-2.1 - rebuilt avahi-0.6.1-2 ------------- * Fri Dec 09 2005 Jason Vas Dias - 0.6.1-2 - fix bug 175352: Do not chkconfig --add avahi-daemon if user has already configured it * Wed Dec 07 2005 Jason Vas Dias - 0.6.1-1 - Upgrade to 0.6.1 * Mon Dec 05 2005 Jason Vas Dias - 0.6-6 - fix bug 174799 - fix .spec file \%files permissions bluez-pin-0.24-3.1 ------------------ * Fri Dec 09 2005 Jesse Keating - 0.24-3.1 - rebuilt bluez-utils-2.22-2.1 -------------------- * Fri Dec 09 2005 Jesse Keating - 2.22-2.1 - rebuilt cairo-1.0.2-3.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt cairo-java-1.0.1-3.1.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt * Fri Dec 09 2005 Igor Foox - 1.0.0-3 - Version bump, for gcc 4.1. checkpolicy-1.28-1 ------------------ * Fri Dec 09 2005 Dan Walsh 1.28-1 - Latest upgrade from NSA dbus-0.60-1.1 ------------- * Fri Dec 09 2005 Jesse Keating - 0.60-1.1 - rebuilt desktop-backgrounds-2.0-30.1 ---------------------------- * Fri Dec 09 2005 Jesse Keating 2.0-30.1 - rebuilt desktop-printing-0.19-4.1 ------------------------- * Fri Dec 09 2005 Jesse Keating - 0.19-4.1 - rebuilt fontconfig-2.3.92.cvs20051129-2 ------------------------------- * Fri Dec 09 2005 Carl Worth - 2.3.92.cvs20051129-2 - Add two new Chinese font names to the default fonts.conf file: AR PL ShanHeiSun Uni AR PL Zenkai Uni * Fri Dec 09 2005 Jesse Keating - rebuilt foomatic-3.0.2-29 ----------------- * Fri Dec 09 2005 Tim Waugh 3.0.2-29 - Updated db-engine to 3.0-20051209. - Updated db-hpijs to 1.5-20051209. - Updated filters to 3.0-20051209. No longer need rip-cvs patch. - Updated db to 3.0-20051209. frysk-0.0.0.20051116-0.5.1.1 ---------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt geronimo-specs-0:1.0-0.M2.2jpp_4fc.1.1 -------------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gettext-0.14.5-2.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt gimp-2:2.2.9-3 -------------- * Fri Dec 09 2005 Nils Philippsen - build with -fomit-frame-pointer to let assembly build with gcc 4.1 * Fri Dec 02 2005 Nils Philippsen - build with gcc 4.1 * Tue Nov 08 2005 Nils Philippsen - don't include .la files (#172626) - require findutils for building glib-1:1.2.10-18.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt * Mon Nov 21 2005 Matthias Clasen 1:1.2.10-18 - Make sure all libraries are stripped * Mon Nov 07 2005 Matthias Clasen 1:1.2.10-17 - Remove .la files and static libs from the -devel package. glib-java-0.2.1-3.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt * Fri Dec 09 2005 Igor Foox - 0.2.1-3 - Version bump to rebuild for gcc4.1 update. gnutls-1.2.9-2 -------------- * Fri Dec 09 2005 Tomas Mraz 1.2.9-2 - replaced *-config scripts with calls to pkg-config to solve multilib conflicts howl-logger-0:0.1.8-1jpp_3fc.1.1 -------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt hsqldb-0:1.80.1-1jpp_4fc.1.1 ---------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt iproute-2.6.14-10 ----------------- * Fri Dec 09 2005 Radek Vokal 2.6.14-10 - remove backup of config files (#175302) jakarta-commons-beanutils-0:1.7.0-2jpp_2fc.1.1 ---------------------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt jakarta-commons-cli-0:1.0-6jpp_1fc.1 ------------------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt jakarta-commons-codec-0:1.3-2jpp_1fc.1.1 ---------------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt jakarta-commons-collections-0:3.1-2jpp_2fc.1.1 ---------------------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt jakarta-commons-dbcp-0:1.2.1-3jpp_2fc.1.1 ----------------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt jakarta-commons-digester-0:1.6-2jpp_6fc.1.1 ------------------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt jakarta-commons-discovery-1:0.3-1jpp_1fc.1 ------------------------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt jakarta-commons-el-0:1.0-4jpp_2fc.1 ----------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt jakarta-commons-fileupload-1:1.0-3jpp_1fc.1.1 --------------------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt jakarta-commons-httpclient-1:3.0-0.rc2.0jpp_1fc.1.1 --------------------------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt jakarta-commons-launcher-0:0.9-3jpp_1fc.1 ----------------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt jakarta-commons-logging-0:1.0.4-2jpp_6fc.1 ------------------------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt jakarta-commons-modeler-0:1.1-4jpp_2fc.1.1 ------------------------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt jakarta-commons-pool-0:1.2-2jpp_2fc.1.1 --------------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt jakarta-commons-validator-0:1.1.3-1jpp_2fc.1 -------------------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt jakarta-taglibs-standard-0:1.1.1-4jpp_1fc.1.1 --------------------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt java-1.4.2-gcj-compat-0:1.4.2.0-40jpp_56rh.1.1 ---------------------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt java_cup-1:0.10-0.k.1jpp_5fc.1.1 -------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt javacc-0:3.2-1jpp_3fc.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt jfsutils-1.1.10-2 ----------------- * Fri Dec 09 2005 Dave Jones - Update to newer upstream 1.1.10 release. * Fri Dec 09 2005 Jesse Keating - rebuilt * Fri Apr 15 2005 Dave Jones - rebuilt. jonathan-core-0:4.1-1jpp_4fc.1 ------------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt jonathan-jeremie-0:4.2-1jpp_4fc.1 --------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt jonathan-rmi-3.1-5.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt joram-0:4.1.5-1jpp_6fc.1.1 -------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt kernel-2.6.14-1.1750_FC5 ------------------------ * Sat Dec 10 2005 David Woodhouse - Work around GCC PR25248 - Fix parport_pc driver to check before poking at legacy I/O ports kudzu-1.2.14-1 -------------- * Fri Dec 09 2005 Bill Nottingham - 1.2.14-1 - add support for mambo virtual devices (#173307, ) libao-0.8.6-1.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libgconf-java-2.12.1-1.1.1 -------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libglade-1:0.17-16.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libgnomecups-0.2.2-3.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libogg-2:1.1.2-2.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt librsvg2-2.13.3-3 ----------------- * Fri Dec 09 2005 Alexander Larsson 2.13.3-3 - Update dependencies (now cairo only, not libart) libsetrans-0.1.11-2 ------------------- * Fri Dec 09 2005 Dan Walsh 0.1.11-1 - Rebuild for libc.so.6 problems libtheora-0:1.0alpha5-1.1 ------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libvorbis-1:1.1.1-1.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt linuxwacom-0:0.7.0-1 -------------------- * Fri Dec 09 2005 Tim Waugh 0:0.7.0-1 - 0.7.0. No longer need 64-bit patch. - Fixed SDK path. nhpf-1.42-9.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt openmotif-2.3.0-0.1.1 --------------------- * Fri Dec 09 2005 Thomas Woerner 2.3.0-0.1.1 - moved mwmrc to /etc/X11/mwm - moved bindings to /usr/share/X11 - fixed paths in man pages containing /usr/X11R6 * Thu Dec 08 2005 Thomas Woerner 2.3.0-0.1.1 - enabled Xft, jpeg and png support - patch for missing xft-config - dropped duplicate include path in devel package * Fri Dec 02 2005 Thomas Woerner 2.3.0-0.1 - new 2.3.0 (beta1) - patch for new rgb.txt location (#174210) Thanks to Ville Skytt?? for the patch perl-3:5.8.7-8 -------------- * Thu Dec 08 2005 Jason Vas Dias - 3.5.8.7-8 - Apply upstream patches 26283 and 26284 : complete, revised fixes for CVE-2005-3962 and CVE-2005-3912 and "Sys::Syslog security vulnerabilities" issues. - Fix bug 136009 / MakeMaker LD_RUN_PATH issue: restore previous default Red Hat behavior of removing the MakeMaker generated LD_RUN_PATH setting from the link command . Document this removal, as it contravenes upstream default behavior, and provide a USE_MM_LD_RUN_PATH MakeMaker member to enable use of the MakeMaker generated LD_RUN_PATH . * Thu Dec 01 2005 Jason Vas Dias - 3:5.8.7-0.8 - fix bug 174684 / CVE-2005-3962: sprintf integer overflow vulnerability backport upstream patch #26240 * Wed Nov 09 2005 Jason Vas Dias - 3:5.8.7-0.7 - fix bug 136009: restore MakeMaker support for LD_RUN_PATH, while removing empty LD_RUN_PATH pm-utils-0.07-4 --------------- * Fri Dec 09 2005 Dave Jones - Update to latest vbetool (0.5-1) Now also built on x86-64 too. * Fri Dec 09 2005 Jesse Keating - rebuilt policycoreutils-1.29.1-2 ------------------------ * Fri Dec 09 2005 Dan Walsh 1.29.1-2 - More fixes to chcat * Fri Dec 09 2005 Jesse Keating - rebuilt rhythmbox-0.8.8-2 ----------------- * Mon Mar 14 2005 Colin Walters - 0.8.8-2 - Rebuild for GCC4 * Tue Oct 05 2004 Colin Walters - 0.8.8-1 - New upstream version - Remove librb-nautilus-context-menu.so, killed upstream * Thu Sep 30 2004 Christopher Aillon 0.8.7-2 - PreReq desktop-file-utils >= 0.9 rhythmbox-0.9.2-3.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt selinux-policy-2.1.2-1 ---------------------- * Fri Dec 09 2005 Dan Walsh 2.1.2-1 - Update to upstream - Turn off allow_execmem and allow_execmod booleans - Add tcpd and automount policies * Thu Dec 08 2005 Dan Walsh 2.1.1-3 - Add two new httpd booleans, turned off by default * httpd_can_network_relay * httpd_can_network_connect_db * Thu Dec 08 2005 Dan Walsh 2.1.1-2 - Add ghost for policy.20 sound-juicer-2.13.1-2.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt totem-1.2.0-2.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt vorbis-tools-1:1.1.1-1.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt xchat-1:2.6.0-3.1 ----------------- * Fri Dec 09 2005 Jesse Keating - 1:2.6.0-3.1 - rebuilt Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 anaconda - 10.90.15-1.i386 requires anaconda-help carol - 1.8.9.3-1jpp_6fc.i386 requires libgcj.so.6 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel = 0:2.6.14-1.1696_FC5 cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5smp cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 ddd - 3.3.11-4.i386 requires libXm.so.3 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 eclipse-bugzilla - 1:0.1.1_fc-5.i386 requires libgcj.so.6 eclipse-cdt - 1:3.0.1-1jpp_1fc.i386 requires libgcj.so.6 eclipse-changelog - 1:2.0.1_fc-22.i386 requires libgcj.so.6 eclipse-ecj - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-jdt - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-pde - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-platform - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-pydev - 1:0.9.3_fc-12.i386 requires libgcj.so.6 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel = 0:2.6.14-1.1696_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 gnu-crypto - 2.0.1-1jpp_8fc.i386 requires libgcj.so.6 gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.i386 requires libgcj.so.6 gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.i386 requires libgcj.so.6 jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jotm - 2.0.5-1jpp_3fc.i386 requires libgcj.so.6 jsch - 0.1.18-1jpp_2fc.i386 requires libgcj.so.6 libglade-java - 2.12.1-2.i386 requires libgcj.so.6 libgnome-java - 2.12.1-2.i386 requires libgcj.so.6 libgtk-java - 2.8.1-1.i386 requires libgcj.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.i386 requires libgcjawt.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 libvte-java - 0.11.11-6.i386 requires libgcj.so.6 lucene - 1.4.3-1jpp_7fc.i386 requires libgcj.so.6 lucene-demo - 1.4.3-1jpp_7fc.i386 requires libgcj.so.6 monolog - 1.8.6-1jpp_5fc.i386 requires libgcj.so.6 mx4j - 1:3.0.1-1jpp_5fc.i386 requires libgcj.so.6 nanoxml - 2.2.3-3jpp_3fc.i386 requires libgcj.so.6 nanoxml-lite - 2.2.3-3jpp_3fc.i386 requires libgcj.so.6 oldkilim - 1.1.3-2jpp_3fc.i386 requires libgcj.so.6 openoffice.org-core - 1:2.0.1-143.1.2.i386 requires libgcjawt.so.6 openoffice.org-core - 1:2.0.1-143.1.2.i386 requires libgcj.so.6 p6spy - 1.3-2jpp_3fc.i386 requires libgcj.so.6 regexp - 1.3-2jpp_3fc.i386 requires libgcj.so.6 struts - 1.2.4-2jpp_3fc.i386 requires libgcj.so.6 struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.i386 requires libgcj.so.6 systemtap - 0.5-2.i386 requires libdw.so.1(ELFUTILS_0.116) tetex-xdvi - 3.0-11.i386 requires libXm.so.3 tomcat5 - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 tomcat5-admin-webapps - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 tomcat5-jasper - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 tomcat5-webapps - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 xalan-j2 - 2.6.0-3jpp_4fc.i386 requires libgcj.so.6 xalan-j2-demo - 2.6.0-3jpp_4fc.i386 requires libgcj.so.6 xalan-j2-xsltc - 2.6.0-3jpp_4fc.i386 requires libgcj.so.6 xerces-j2 - 2.6.2-5jpp_2fc.i386 requires libgcj.so.6 xerces-j2-demo - 2.6.2-5jpp_2fc.i386 requires libgcj.so.6 xml-commons-apis - 1.0-0.b2.7jpp_3fc.i386 requires libgcj.so.6 xml-commons-which - 1.0-0.b2.7jpp_3fc.i386 requires libgcj.so.6 xpdf - 1:3.01-5.i386 requires libXm.so.3 Broken deps for ia64 ---------------------------------------------------------- anaconda - 10.90.15-1.ia64 requires anaconda-help carol - 1.8.9.3-1jpp_6fc.ia64 requires libgcj.so.6()(64bit) ddd - 3.3.11-4.ia64 requires libXm.so.3()(64bit) gnu-crypto - 2.0.1-1jpp_8fc.ia64 requires libgcj.so.6()(64bit) gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.ia64 requires libgcj.so.6()(64bit) gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.ia64 requires libgcj.so.6()(64bit) jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) jotm - 2.0.5-1jpp_3fc.ia64 requires libgcj.so.6()(64bit) jsch - 0.1.18-1jpp_2fc.ia64 requires libgcj.so.6()(64bit) libglade-java - 2.12.1-2.ia64 requires libgcj.so.6()(64bit) libgnome-java - 2.12.1-2.ia64 requires libgcj.so.6()(64bit) libgtk-java - 2.8.1-1.ia64 requires libgcj.so.6()(64bit) libsetrans - 0.1.11-2.ia64 requires libc.so.6(GLIBC_2.3.4) libsetrans - 0.1.11-2.ia64 requires libc.so.6(GLIBC_2.4) libsetrans - 0.1.11-2.ia64 requires libc.so.6(GLIBC_2.1) libsetrans - 0.1.11-2.ia64 requires libc.so.6(GLIBC_2.0) libsetrans - 0.1.11-2.ia64 requires libdl.so.2 libsetrans - 0.1.11-2.ia64 requires libc.so.6(GLIBC_2.1.3) libsetrans - 0.1.11-2.ia64 requires libc.so.6(GLIBC_2.3) libsetrans - 0.1.11-2.ia64 requires libc.so.6 libsetrans - 0.1.11-2.ia64 requires libselinux.so.1 libvte-java - 0.11.11-6.ia64 requires libgcj.so.6()(64bit) lucene - 1.4.3-1jpp_7fc.ia64 requires libgcj.so.6()(64bit) lucene-demo - 1.4.3-1jpp_7fc.ia64 requires libgcj.so.6()(64bit) monolog - 1.8.6-1jpp_5fc.ia64 requires libgcj.so.6()(64bit) mx4j - 1:3.0.1-1jpp_5fc.ia64 requires libgcj.so.6()(64bit) nanoxml - 2.2.3-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) nanoxml-lite - 2.2.3-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) oldkilim - 1.1.3-2jpp_3fc.ia64 requires libgcj.so.6()(64bit) p6spy - 1.3-2jpp_3fc.ia64 requires libgcj.so.6()(64bit) regexp - 1.3-2jpp_3fc.ia64 requires libgcj.so.6()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs struts - 1.2.4-2jpp_3fc.ia64 requires libgcj.so.6()(64bit) struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.ia64 requires libgcj.so.6()(64bit) systemtap - 0.5-2.ia64 requires libdw.so.1(ELFUTILS_0.116)(64bit) tetex-xdvi - 3.0-11.ia64 requires libXm.so.3()(64bit) tomcat5 - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) tomcat5-admin-webapps - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) tomcat5-jasper - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) tomcat5-webapps - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) xalan-j2 - 2.6.0-3jpp_4fc.ia64 requires libgcj.so.6()(64bit) xalan-j2-demo - 2.6.0-3jpp_4fc.ia64 requires libgcj.so.6()(64bit) xalan-j2-xsltc - 2.6.0-3jpp_4fc.ia64 requires libgcj.so.6()(64bit) xerces-j2 - 2.6.2-5jpp_2fc.ia64 requires libgcj.so.6()(64bit) xerces-j2-demo - 2.6.2-5jpp_2fc.ia64 requires libgcj.so.6()(64bit) xml-commons-apis - 1.0-0.b2.7jpp_3fc.ia64 requires libgcj.so.6()(64bit) xml-commons-which - 1.0-0.b2.7jpp_3fc.ia64 requires libgcj.so.6()(64bit) xpdf - 1:3.01-5.ia64 requires libXm.so.3()(64bit) Broken deps for ppc ---------------------------------------------------------- anaconda - 10.90.15-1.ppc requires anaconda-help carol - 1.8.9.3-1jpp_6fc.ppc requires libgcj.so.6 cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 ddd - 3.3.11-4.ppc requires libXm.so.3 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 eclipse-bugzilla - 1:0.1.1_fc-5.ppc requires libgcj.so.6 eclipse-cdt - 1:3.0.1-1jpp_1fc.ppc requires libgcj.so.6 eclipse-changelog - 1:2.0.1_fc-22.ppc requires libgcj.so.6 eclipse-ecj - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-jdt - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-pde - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-platform - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-pydev - 1:0.9.3_fc-12.ppc requires libgcj.so.6 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 gnu-crypto - 2.0.1-1jpp_8fc.ppc requires libgcj.so.6 gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.ppc requires libgcj.so.6 gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.ppc requires libgcj.so.6 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jotm - 2.0.5-1jpp_3fc.ppc requires libgcj.so.6 jsch - 0.1.18-1jpp_2fc.ppc requires libgcj.so.6 libglade-java - 2.12.1-2.ppc requires libgcj.so.6 libgnome-java - 2.12.1-2.ppc requires libgcj.so.6 libgtk-java - 2.8.1-1.ppc requires libgcj.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.ppc requires libgcjawt.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 libvte-java - 0.11.11-6.ppc requires libgcj.so.6 lucene - 1.4.3-1jpp_7fc.ppc requires libgcj.so.6 lucene-demo - 1.4.3-1jpp_7fc.ppc requires libgcj.so.6 monolog - 1.8.6-1jpp_5fc.ppc requires libgcj.so.6 mx4j - 1:3.0.1-1jpp_5fc.ppc requires libgcj.so.6 nanoxml - 2.2.3-3jpp_3fc.ppc requires libgcj.so.6 nanoxml-lite - 2.2.3-3jpp_3fc.ppc requires libgcj.so.6 oldkilim - 1.1.3-2jpp_3fc.ppc requires libgcj.so.6 openoffice.org-core - 1:2.0.1-143.1.2.ppc requires libgcjawt.so.6 openoffice.org-core - 1:2.0.1-143.1.2.ppc requires libgcj.so.6 p6spy - 1.3-2jpp_3fc.ppc requires libgcj.so.6 regexp - 1.3-2jpp_3fc.ppc requires libgcj.so.6 struts - 1.2.4-2jpp_3fc.ppc requires libgcj.so.6 struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.ppc requires libgcj.so.6 systemtap - 0.5-2.ppc requires libdw.so.1(ELFUTILS_0.116) tetex-xdvi - 3.0-11.ppc requires libXm.so.3 tomcat5 - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 tomcat5-admin-webapps - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 tomcat5-jasper - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 tomcat5-webapps - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 xalan-j2 - 2.6.0-3jpp_4fc.ppc requires libgcj.so.6 xalan-j2-demo - 2.6.0-3jpp_4fc.ppc requires libgcj.so.6 xalan-j2-xsltc - 2.6.0-3jpp_4fc.ppc requires libgcj.so.6 xerces-j2 - 2.6.2-5jpp_2fc.ppc requires libgcj.so.6 xerces-j2-demo - 2.6.2-5jpp_2fc.ppc requires libgcj.so.6 xml-commons-apis - 1.0-0.b2.7jpp_3fc.ppc requires libgcj.so.6 xml-commons-which - 1.0-0.b2.7jpp_3fc.ppc requires libgcj.so.6 xpdf - 1:3.01-5.ppc requires libXm.so.3 Broken deps for ppc64 ---------------------------------------------------------- anaconda - 10.90.15-1.ppc64 requires anaconda-help carol - 1.8.9.3-1jpp_6fc.ppc64 requires libgcj.so.6()(64bit) cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 ddd - 3.3.11-4.ppc64 requires libXm.so.3()(64bit) dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 gnu-crypto - 2.0.1-1jpp_8fc.ppc64 requires libgcj.so.6()(64bit) gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.ppc64 requires libgcj.so.6()(64bit) gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.ppc64 requires libgcj.so.6()(64bit) jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) jotm - 2.0.5-1jpp_3fc.ppc64 requires libgcj.so.6()(64bit) jsch - 0.1.18-1jpp_2fc.ppc64 requires libgcj.so.6()(64bit) libglade-java - 2.12.1-2.ppc64 requires libgcj.so.6()(64bit) libgnome-java - 2.12.1-2.ppc64 requires libgcj.so.6()(64bit) libgtk-java - 2.8.1-1.ppc64 requires libgcj.so.6()(64bit) libsetrans - 0.1.11-2.ppc64 requires libc.so.6(GLIBC_2.3.4) libsetrans - 0.1.11-2.ppc64 requires libc.so.6(GLIBC_2.4) libsetrans - 0.1.11-2.ppc64 requires libc.so.6(GLIBC_2.1) libsetrans - 0.1.11-2.ppc64 requires libc.so.6(GLIBC_2.0) libsetrans - 0.1.11-2.ppc64 requires libdl.so.2 libsetrans - 0.1.11-2.ppc64 requires libc.so.6(GLIBC_2.1.3) libsetrans - 0.1.11-2.ppc64 requires libc.so.6(GLIBC_2.3) libsetrans - 0.1.11-2.ppc64 requires libc.so.6 libsetrans - 0.1.11-2.ppc64 requires libselinux.so.1 libvte-java - 0.11.11-6.ppc64 requires libgcj.so.6()(64bit) lucene - 1.4.3-1jpp_7fc.ppc64 requires libgcj.so.6()(64bit) lucene-demo - 1.4.3-1jpp_7fc.ppc64 requires libgcj.so.6()(64bit) monolog - 1.8.6-1jpp_5fc.ppc64 requires libgcj.so.6()(64bit) mx4j - 1:3.0.1-1jpp_5fc.ppc64 requires libgcj.so.6()(64bit) nanoxml - 2.2.3-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) nanoxml-lite - 2.2.3-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) oldkilim - 1.1.3-2jpp_3fc.ppc64 requires libgcj.so.6()(64bit) p6spy - 1.3-2jpp_3fc.ppc64 requires libgcj.so.6()(64bit) regexp - 1.3-2jpp_3fc.ppc64 requires libgcj.so.6()(64bit) struts - 1.2.4-2jpp_3fc.ppc64 requires libgcj.so.6()(64bit) struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.ppc64 requires libgcj.so.6()(64bit) tetex-xdvi - 3.0-11.ppc64 requires libXm.so.3()(64bit) tomcat5 - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) tomcat5-admin-webapps - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) tomcat5-jasper - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) tomcat5-webapps - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) xalan-j2 - 2.6.0-3jpp_4fc.ppc64 requires libgcj.so.6()(64bit) xalan-j2-demo - 2.6.0-3jpp_4fc.ppc64 requires libgcj.so.6()(64bit) xalan-j2-xsltc - 2.6.0-3jpp_4fc.ppc64 requires libgcj.so.6()(64bit) xerces-j2 - 2.6.2-5jpp_2fc.ppc64 requires libgcj.so.6()(64bit) xerces-j2-demo - 2.6.2-5jpp_2fc.ppc64 requires libgcj.so.6()(64bit) xml-commons-apis - 1.0-0.b2.7jpp_3fc.ppc64 requires libgcj.so.6()(64bit) xml-commons-which - 1.0-0.b2.7jpp_3fc.ppc64 requires libgcj.so.6()(64bit) xpdf - 1:3.01-5.ppc64 requires libXm.so.3()(64bit) Broken deps for s390 ---------------------------------------------------------- anaconda - 10.90.15-1.s390 requires anaconda-help carol - 1.8.9.3-1jpp_6fc.s390 requires libgcj.so.6 ddd - 3.3.11-4.s390 requires libXm.so.3 gnu-crypto - 2.0.1-1jpp_8fc.s390 requires libgcj.so.6 gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.s390 requires libgcj.so.6 gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.s390 requires libgcj.so.6 jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jotm - 2.0.5-1jpp_3fc.s390 requires libgcj.so.6 jsch - 0.1.18-1jpp_2fc.s390 requires libgcj.so.6 libglade-java - 2.12.1-2.s390 requires libgcj.so.6 libgnome-java - 2.12.1-2.s390 requires libgcj.so.6 libgtk-java - 2.8.1-1.s390 requires libgcj.so.6 libvte-java - 0.11.11-6.s390 requires libgcj.so.6 lucene - 1.4.3-1jpp_7fc.s390 requires libgcj.so.6 lucene-demo - 1.4.3-1jpp_7fc.s390 requires libgcj.so.6 monolog - 1.8.6-1jpp_5fc.s390 requires libgcj.so.6 mx4j - 1:3.0.1-1jpp_5fc.s390 requires libgcj.so.6 nanoxml - 2.2.3-3jpp_3fc.s390 requires libgcj.so.6 nanoxml-lite - 2.2.3-3jpp_3fc.s390 requires libgcj.so.6 oldkilim - 1.1.3-2jpp_3fc.s390 requires libgcj.so.6 p6spy - 1.3-2jpp_3fc.s390 requires libgcj.so.6 regexp - 1.3-2jpp_3fc.s390 requires libgcj.so.6 struts - 1.2.4-2jpp_3fc.s390 requires libgcj.so.6 struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.s390 requires libgcj.so.6 tetex-xdvi - 3.0-11.s390 requires libXm.so.3 tomcat5 - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 tomcat5-admin-webapps - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 tomcat5-jasper - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 tomcat5-webapps - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 xalan-j2 - 2.6.0-3jpp_4fc.s390 requires libgcj.so.6 xalan-j2-demo - 2.6.0-3jpp_4fc.s390 requires libgcj.so.6 xalan-j2-xsltc - 2.6.0-3jpp_4fc.s390 requires libgcj.so.6 xerces-j2 - 2.6.2-5jpp_2fc.s390 requires libgcj.so.6 xerces-j2-demo - 2.6.2-5jpp_2fc.s390 requires libgcj.so.6 xml-commons-apis - 1.0-0.b2.7jpp_3fc.s390 requires libgcj.so.6 xml-commons-which - 1.0-0.b2.7jpp_3fc.s390 requires libgcj.so.6 xpdf - 1:3.01-5.s390 requires libXm.so.3 Broken deps for s390x ---------------------------------------------------------- anaconda - 10.90.15-1.s390x requires anaconda-help carol - 1.8.9.3-1jpp_6fc.s390x requires libgcj.so.6()(64bit) ddd - 3.3.11-4.s390x requires libXm.so.3()(64bit) gnu-crypto - 2.0.1-1jpp_8fc.s390x requires libgcj.so.6()(64bit) gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.s390x requires libgcj.so.6()(64bit) gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.s390x requires libgcj.so.6()(64bit) jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) jotm - 2.0.5-1jpp_3fc.s390x requires libgcj.so.6()(64bit) jsch - 0.1.18-1jpp_2fc.s390x requires libgcj.so.6()(64bit) libgconf-java - 2.12.0-2.s390x requires libgcj.so.6()(64bit) libgconf-java - 2.12.0-2.s390x requires libglibjava-0.2.so()(64bit) libgconf-java - 2.12.0-2.s390x requires libglibjni-0.2.so()(64bit) libgconf-java - 2.12.0-2.s390x requires libcairojava-1.0.so()(64bit) libglade-java - 2.12.0-5.s390x requires libgcj.so.6()(64bit) libglade-java - 2.12.0-5.s390x requires libglibjava-0.2.so()(64bit) libglade-java - 2.12.0-5.s390x requires libglibjni-0.2.so()(64bit) libglade-java - 2.12.0-5.s390x requires libcairojava-1.0.so()(64bit) libgnome-java - 2.12.0-2.s390x requires libgcj.so.6()(64bit) libgnome-java - 2.12.0-2.s390x requires libglibjava-0.2.so()(64bit) libgnome-java - 2.12.0-2.s390x requires libglibjni-0.2.so()(64bit) libgnome-java - 2.12.0-2.s390x requires libcairojava-1.0.so()(64bit) libgtk-java - 2.8.0-7.s390x requires libgcj.so.6()(64bit) libgtk-java - 2.8.0-7.s390x requires libglibjava-0.2.so()(64bit) libgtk-java - 2.8.0-7.s390x requires libglibjni-0.2.so()(64bit) libvte-java - 0.11.11-6.s390x requires libgcj.so.6()(64bit) libvte-java - 0.11.11-6.s390x requires libglibjava-0.2.so()(64bit) libvte-java - 0.11.11-6.s390x requires libglibjni-0.2.so()(64bit) libvte-java - 0.11.11-6.s390x requires libcairojava-1.0.so()(64bit) lucene - 1.4.3-1jpp_7fc.s390x requires libgcj.so.6()(64bit) lucene-demo - 1.4.3-1jpp_7fc.s390x requires libgcj.so.6()(64bit) monolog - 1.8.6-1jpp_5fc.s390x requires libgcj.so.6()(64bit) mx4j - 1:3.0.1-1jpp_5fc.s390x requires libgcj.so.6()(64bit) nanoxml - 2.2.3-3jpp_3fc.s390x requires libgcj.so.6()(64bit) nanoxml-lite - 2.2.3-3jpp_3fc.s390x requires libgcj.so.6()(64bit) oldkilim - 1.1.3-2jpp_3fc.s390x requires libgcj.so.6()(64bit) p6spy - 1.3-2jpp_3fc.s390x requires libgcj.so.6()(64bit) regexp - 1.3-2jpp_3fc.s390x requires libgcj.so.6()(64bit) struts - 1.2.4-2jpp_3fc.s390x requires libgcj.so.6()(64bit) struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.s390x requires libgcj.so.6()(64bit) tetex-xdvi - 3.0-11.s390x requires libXm.so.3()(64bit) tomcat5 - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) tomcat5-admin-webapps - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) tomcat5-jasper - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) tomcat5-webapps - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) xalan-j2 - 2.6.0-3jpp_4fc.s390x requires libgcj.so.6()(64bit) xalan-j2-demo - 2.6.0-3jpp_4fc.s390x requires libgcj.so.6()(64bit) xalan-j2-xsltc - 2.6.0-3jpp_4fc.s390x requires libgcj.so.6()(64bit) xerces-j2 - 2.6.2-5jpp_2fc.s390x requires libgcj.so.6()(64bit) xerces-j2-demo - 2.6.2-5jpp_2fc.s390x requires libgcj.so.6()(64bit) xml-commons-apis - 1.0-0.b2.7jpp_3fc.s390x requires libgcj.so.6()(64bit) xml-commons-which - 1.0-0.b2.7jpp_3fc.s390x requires libgcj.so.6()(64bit) xpdf - 1:3.01-5.s390x requires libXm.so.3()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 anaconda - 10.90.15-1.x86_64 requires anaconda-help carol - 1.8.9.3-1jpp_6fc.x86_64 requires libgcj.so.6()(64bit) cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 ddd - 3.3.11-4.x86_64 requires libXm.so.3()(64bit) dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 eclipse-bugzilla - 1:0.1.1_fc-5.x86_64 requires libgcj.so.6()(64bit) eclipse-cdt - 1:3.0.1-1jpp_1fc.x86_64 requires libgcj.so.6()(64bit) eclipse-changelog - 1:2.0.1_fc-22.x86_64 requires libgcj.so.6()(64bit) eclipse-ecj - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-jdt - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-pde - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-platform - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-pydev - 1:0.9.3_fc-12.x86_64 requires libgcj.so.6()(64bit) gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 gnu-crypto - 2.0.1-1jpp_8fc.x86_64 requires libgcj.so.6()(64bit) gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.x86_64 requires libgcj.so.6()(64bit) gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.x86_64 requires libgcj.so.6()(64bit) jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jotm - 2.0.5-1jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jsch - 0.1.18-1jpp_2fc.x86_64 requires libgcj.so.6()(64bit) libglade-java - 2.12.1-2.x86_64 requires libgcj.so.6()(64bit) libgnome-java - 2.12.1-2.x86_64 requires libgcj.so.6()(64bit) libgtk-java - 2.8.1-1.x86_64 requires libgcj.so.6()(64bit) libswt3-gtk2 - 1:3.1.1-1jpp_9fc.x86_64 requires libgcjawt.so.6()(64bit) libswt3-gtk2 - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) libvte-java - 0.11.11-6.x86_64 requires libgcj.so.6()(64bit) lucene - 1.4.3-1jpp_7fc.x86_64 requires libgcj.so.6()(64bit) lucene-demo - 1.4.3-1jpp_7fc.x86_64 requires libgcj.so.6()(64bit) monolog - 1.8.6-1jpp_5fc.x86_64 requires libgcj.so.6()(64bit) mx4j - 1:3.0.1-1jpp_5fc.x86_64 requires libgcj.so.6()(64bit) nanoxml - 2.2.3-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) nanoxml-lite - 2.2.3-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) oldkilim - 1.1.3-2jpp_3fc.x86_64 requires libgcj.so.6()(64bit) openoffice.org-core - 1:2.0.1-143.1.2.i386 requires libgcjawt.so.6 openoffice.org-core - 1:2.0.1-143.1.2.i386 requires libgcj.so.6 p6spy - 1.3-2jpp_3fc.x86_64 requires libgcj.so.6()(64bit) regexp - 1.3-2jpp_3fc.x86_64 requires libgcj.so.6()(64bit) struts - 1.2.4-2jpp_3fc.x86_64 requires libgcj.so.6()(64bit) struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.x86_64 requires libgcj.so.6()(64bit) systemtap - 0.5-2.x86_64 requires libdw.so.1(ELFUTILS_0.116)(64bit) tetex-xdvi - 3.0-11.x86_64 requires libXm.so.3()(64bit) tomcat5 - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) tomcat5-admin-webapps - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) tomcat5-jasper - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) tomcat5-webapps - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) xalan-j2 - 2.6.0-3jpp_4fc.x86_64 requires libgcj.so.6()(64bit) xalan-j2-demo - 2.6.0-3jpp_4fc.x86_64 requires libgcj.so.6()(64bit) xalan-j2-xsltc - 2.6.0-3jpp_4fc.x86_64 requires libgcj.so.6()(64bit) xerces-j2 - 2.6.2-5jpp_2fc.x86_64 requires libgcj.so.6()(64bit) xerces-j2-demo - 2.6.2-5jpp_2fc.x86_64 requires libgcj.so.6()(64bit) xml-commons-apis - 1.0-0.b2.7jpp_3fc.x86_64 requires libgcj.so.6()(64bit) xml-commons-which - 1.0-0.b2.7jpp_3fc.x86_64 requires libgcj.so.6()(64bit) xpdf - 1:3.01-5.x86_64 requires libXm.so.3()(64bit) From sundaram at redhat.com Sat Dec 10 11:54:28 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Sat, 10 Dec 2005 17:24:28 +0530 Subject: yum clean bug In-Reply-To: <6280325c0512090906k7a8ffa0fn43e71eedf557acdd@mail.gmail.com> References: <4398BA2B.2040607@n-man.com> <4398E2A7.5030102@poolshark.org> <604aa7910512081855ma19bf3bx5599989dc0e44f16@mail.gmail.com> <4399358A.2060005@laposte.net> <1134141515.3010.34.camel@yoda.loki.me> <6280325c0512090739y6fb8d79bt1f760c1e0032c338@mail.gmail.com> <4399A5B5.90603@redhat.com> <6280325c0512090906k7a8ffa0fn43e71eedf557acdd@mail.gmail.com> Message-ID: <439AC1F4.4010807@redhat.com> Hi > >I think it is a good idea too. >However I feel a distinct lack of motivation for submitting a new >feature when the developers just dismiss ideas casually and say that >feature will never have a chance of inclusion. So even if everyone >that uses a new plugin from yum-utils says it is the best thing since >sliced bread and they all want it in yum, it probably won't ever see >the light of day -- after all, the developers said it would never be >considered, right? Will yum-utils then just become a place to stash >any unwanted features? > > Its not unwanted. Merely something that doesnt fit with yum. yum-utils is a set of utilities and possibly plugins that extend the core functionality of yum. Some of them dont belong in core yum in anyway. Others might eventually get merged but its always the developers freedom to say no in cases where they disagree with it. There was some ambiguity in the man page which has now been fixed. Fortunately due the extension mechanism adding new features is a easy thing to do akin to say Firefox. Go ahead and code whatever functionality you need and post to yum-devel list and get it included within yum-utils. If users want it they will use it. >As a side note, how many people actually have yum-utils and are aware >of all it's features? There is once again very little motivation to >submit to something that won't be used or even known about. Maybe the >yum-utils structure could be improved to better incorporate plugins, >or maybe a whole new yum-plugins package could be made. It would be >nice to have a man page as well to (tersely if necessary) describe all >the included features. Please note that I would be happy to attempt >such a project if people think it is worthwhile. > > As I have said in the list before yum-utils needs better visibility. You can work on documentation such as man page, Fedora Yum guide, writing articles in fedora news or Red Hat magazine. Split up plugins into seperate packages etc. I think thats much more worthwhile than this discussion regards Rahul From wrrhdev at riede.org Sat Dec 10 14:35:41 2005 From: wrrhdev at riede.org (Willem Riede) Date: Sat, 10 Dec 2005 14:35:41 +0000 Subject: yum clean bug In-Reply-To: (from tmus@tmus.dk on Thu Dec 8 18:03:00 2005) References: <1134074565.23944.39.camel@cutter> <20051208205137.GA10102@nsk.no-ip.org> <604aa7910512081255y613cdbe0m33b2a4fae45471b@mail.gmail.com> <1134078696.1536.1.camel@weasel.turre.laiskiainen.org> <1134079174.23944.48.camel@cutter> <1134081726.23944.61.camel@cutter> Message-ID: <1134225341l.19184l.7l@serve.riede.org> On 12/08/2005 06:03:00 PM, Thomas M Steenholdt wrote: > > If the repo is disabled - it means that the user don't care about that repo. I don't think that's true... It just means (s)he doesn't use that repo by default. It could be a repo from which the user occasionally gets (updates) a few very specific rpms using yum --enablerepo. Regards, Willem Riede. From jdieter99 at gmx.net Sat Dec 10 14:50:25 2005 From: jdieter99 at gmx.net (Jonathan Dieter) Date: Sat, 10 Dec 2005 16:50:25 +0200 Subject: Delta RPM status? Message-ID: <439AEB31.6030502@gmx.net> What is the current status of delta RPMS? I've developed a python implementation that can create a byte-for-byte duplicate of the update RPM from the delta using a modified bsdiff algorithm, but apparently I've been duplicating others' work. My implementation works on a file-by-file basis rather than archive by archive and will work even if configuration files have been changed (by storing said files in patch as new files rather than as deltas). It also can either use the user's file-system or an original RPM as it's source for applying the delta. However, I realize all this may be a moot point if there's already something out there that provides the same functionality. I hope I haven't stepped on anyone's toes. Thanks, Jonathan From jdesbonnet at gmail.com Sat Dec 10 14:56:51 2005 From: jdesbonnet at gmail.com (Joe Desbonnet) Date: Sat, 10 Dec 2005 14:56:51 +0000 Subject: Delta RPM status? In-Reply-To: <439AEB31.6030502@gmx.net> References: <439AEB31.6030502@gmx.net> Message-ID: <1cef3e950512100656h2dd3e674s2043c9b3c21bfabe@mail.gmail.com> I've done some work on this and I have a link to other related projects at the bottom of this document: http://www.wombat.ie/software/rpmdc/releasenotes-0.1.1.html In particular see link for Delta RPM by Michael Schroeder. Michael has been gently suggesting that we use his software in Fedora -- which I would agree with. I hope to do more work on this in Jan 2006 when I hope to have more free time. Joe. On 12/10/05, Jonathan Dieter wrote: > What is the current status of delta RPMS? I've developed a python > implementation that can create a byte-for-byte duplicate of the update > RPM from the delta using a modified bsdiff algorithm, but apparently > I've been duplicating others' work. My implementation works on a > file-by-file basis rather than archive by archive and will work even if > configuration files have been changed (by storing said files in patch as > new files rather than as deltas). It also can either use the user's > file-system or an original RPM as it's source for applying the delta. > > However, I realize all this may be a moot point if there's already > something out there that provides the same functionality. I hope I > haven't stepped on anyone's toes. Thanks, > > Jonathan > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From wrrhdev at riede.org Sat Dec 10 15:01:52 2005 From: wrrhdev at riede.org (Willem Riede) Date: Sat, 10 Dec 2005 15:01:52 +0000 Subject: yum clean bug In-Reply-To: <4399E4A8.5060201@laposte.net> (from nicolas.mailhot@laposte.net on Fri Dec 9 15:10:16 2005) References: <22905.192.54.193.25.1134142460.squirrel@rousalka.dyndns.org> <1134142976.3010.39.camel@yoda.loki.me> <4399BE90.7080809@laposte.net> <1134150137.3010.75.camel@yoda.loki.me> <4399C652.9090902@laposte.net> <1134151788.3010.84.camel@yoda.loki.me> <4399CF6E.6010906@laposte.net> <604aa7910512091100r5df30972w2092a9385a30fdc4@mail.gmail.com> <4399D79C.208@laposte.net> <604aa7910512091134j6ccaf0aeia4810633781e9e06@mail.gmail.com> <4399E4A8.5060201@laposte.net> Message-ID: <1134226912l.19184l.8l@serve.riede.org> On 12/09/2005 03:10:16 PM, Nicolas Mailhot wrote: > > 1. shouldn't yum remove every part of /var/cache/yum not covered by a > repo (enabled or not) since obviously it can not use it for optimization > purposes ? (this would correspond to standard home-keeping after repo > removal/renaming). Other tools routinely remove this kind of leftovers > or at least flag them (yum leftovers can be huge, a repo can consume > hundreds of MiBs in old downloaded packages, and people seem to like > renaming repositories). Unless there is some other reason to keep it ? > (but then it does not belong in /var/cache/yum anymore) Are you effectively arguing for a --deleterepo= option, where this would remove both the .repo file and /var/cache/yum/ plus contents? Other than that, I'm with everybody else that thinks the current behavior is just fine. Regards, Willem Riede. From laroche at redhat.com Sat Dec 10 16:12:17 2005 From: laroche at redhat.com (Florian La Roche) Date: Sat, 10 Dec 2005 17:12:17 +0100 Subject: Delta RPM status? In-Reply-To: <1cef3e950512100656h2dd3e674s2043c9b3c21bfabe@mail.gmail.com> References: <439AEB31.6030502@gmx.net> <1cef3e950512100656h2dd3e674s2043c9b3c21bfabe@mail.gmail.com> Message-ID: <20051210161217.GA5517@dudweiler.stuttgart.redhat.com> On Sat, Dec 10, 2005 at 02:56:51PM +0000, Joe Desbonnet wrote: > I've done some work on this and I have a link to other related > projects at the bottom > of this document: > http://www.wombat.ie/software/rpmdc/releasenotes-0.1.1.html Hello Joe, I've added the above url to http://people.redhat.com/laroche/pyrpm/ to the link section. For diff algorithms we've seen pretty good results with "edelta", so you might want to add that to your tests as well. regards, Florian La Roche From nicolas.mailhot at laposte.net Sat Dec 10 16:40:51 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sat, 10 Dec 2005 17:40:51 +0100 Subject: yum clean bug In-Reply-To: <1134226912l.19184l.8l@serve.riede.org> References: <22905.192.54.193.25.1134142460.squirrel@rousalka.dyndns.org> <1134142976.3010.39.camel@yoda.loki.me> <4399BE90.7080809@laposte.net> <1134150137.3010.75.camel@yoda.loki.me> <4399C652.9090902@laposte.net> <1134151788.3010.84.camel@yoda.loki.me> <4399CF6E.6010906@laposte.net> <604aa7910512091100r5df30972w2092a9385a30fdc4@mail.gmail.com> <4399D79C.208@laposte.net> <604aa7910512091134j6ccaf0aeia4810633781e9e06@mail.gmail.com> <4399E4A8.5060201@laposte.net> <1134226912l.19184l.8l@serve.riede.org> Message-ID: <439B0513.4050706@laposte.net> Willem Riede wrote: > On 12/09/2005 03:10:16 PM, Nicolas Mailhot wrote: >> >> 1. shouldn't yum remove every part of /var/cache/yum not covered by a >> repo (enabled or not) since obviously it can not use it for optimization >> purposes ? (this would correspond to standard home-keeping after repo >> removal/renaming). Other tools routinely remove this kind of leftovers >> or at least flag them (yum leftovers can be huge, a repo can consume >> hundreds of MiBs in old downloaded packages, and people seem to like >> renaming repositories). Unless there is some other reason to keep it ? >> (but then it does not belong in /var/cache/yum anymore) > > Are you effectively arguing for a --deleterepo= option, where this > would remove both the .repo file and /var/cache/yum/ plus > contents? No, I'm arguing for yum doing its own housekeeping, ie remove all stuff in /var/cache/yum no longer tracked by a repo file (enabled or not) If yum does not do it, the admin will just wipe out everything which will remove useful cache info with the various other yum leftovers. Or the admin won't do it at all, and yum is leaking hundreds of megs of data in the filesystem Either way, you loose. -- Nicolas Mailhot From ndbecker2 at gmail.com Sat Dec 10 16:58:34 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Sat, 10 Dec 2005 11:58:34 -0500 Subject: Dependency problem with fc4 updates? Message-ID: Looks like gsm update is missing? sudo yum --disablerepo=dries upgrade Setting up Upgrade Process Setting up repositories Reading repository metadata in from local files Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package libavc1394.x86_64 0:0.5.1-0.2.fc4 set to be updated ---> Package ffmpeg-libpostproc.x86_64 0:0.4.9-0.3.20051207.2.fc4 set to be updated ---> Package mjpegtools.x86_64 0:1.8.0-1.2.fc4 set to be updated ---> Package libdvbpsi-devel.x86_64 0:0.1.5-1.2.fc4 set to be updated ---> Package transcode.x86_64 0:1.0.2-2.2.fc4 set to be updated ---> Package mjpegtools-devel.x86_64 0:1.8.0-1.2.fc4 set to be updated ---> Package libdvbpsi.x86_64 0:0.1.5-1.2.fc4 set to be updated ---> Package libavc1394-devel.x86_64 0:0.5.1-0.2.fc4 set to be updated ---> Package ffmpeg-devel.x86_64 0:0.4.9-0.3.20051207.2.fc4 set to be updated ---> Package kino.x86_64 0:0.8.0-1.2.fc4 set to be updated ---> Package ffmpeg.x86_64 0:0.4.9-0.3.20051207.2.fc4 set to be updated --> Running transaction check --> Processing Dependency: x264-devel for package: ffmpeg-devel --> Processing Dependency: libdca-devel for package: ffmpeg-devel --> Processing Dependency: gsm-devel for package: ffmpeg-devel --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. ---> Package x264-devel.x86_64 0:0.0.380-2.2.fc4 set to be updated ---> Package gsm-devel.x86_64 0:1.0.10-5.2.fc4 set to be updated ---> Package libdca.x86_64 0:0.0.2-2.2.fc4 set to be updated --> Running transaction check --> Processing Dependency: gsm = 1.0.10-5.2.fc4 for package: gsm-devel --> Finished Dependency Resolution Error: Missing Dependency: gsm = 1.0.10-5.2.fc4 is needed by package gsm-devel From lists at wilsonet.com Sat Dec 10 17:11:24 2005 From: lists at wilsonet.com (Jarod Wilson) Date: Sat, 10 Dec 2005 09:11:24 -0800 Subject: yum clean bug In-Reply-To: <1134203874.2183.40.camel@cutter> References: <1134203874.2183.40.camel@cutter> Message-ID: <200512100911.24676.lists@wilsonet.com> On Saturday 10 December 2005 00:37, seth vidal wrote: > > Well, Seth has spoken on the topic and it seems that people have actually > > found uses for this behavior. I'll update the manpage to refer to the > > fact that the clean operations only operate on enabled repositories, end > > of story, ok? Before this thread gets any more ridiculous than it already > > is... > > How about we just say that all yum operations will only act on enabled > repositories? Just so there is no doubt that disabled repos are not > acted on. How 'bout adding a config option to yum.conf? Default setting for the "cleanall" option could be "enabled-only", users could switch that to "nuke-everything", or something along those lines. Seems like a reasonable compromise that gives both sides of the fence what they want, no? -- Jarod Wilson jarod at wilsonet.com From mattdm at mattdm.org Sat Dec 10 17:24:44 2005 From: mattdm at mattdm.org (Matthew Miller) Date: Sat, 10 Dec 2005 12:24:44 -0500 Subject: yum clean bug In-Reply-To: <200512100911.24676.lists@wilsonet.com> References: <1134203874.2183.40.camel@cutter> <200512100911.24676.lists@wilsonet.com> Message-ID: <20051210172444.GA21442@jadzia.bu.edu> On Sat, Dec 10, 2005 at 09:11:24AM -0800, Jarod Wilson wrote: > How 'bout adding a config option to yum.conf? Default setting for the > "cleanall" option could be "enabled-only", users could switch that to > "nuke-everything", or something along those lines. Seems like a reasonable > compromise that gives both sides of the fence what they want, no? I think that makes it worse, since you'd never know what clean all does on a given machine without checking the config. -- Matthew Miller mattdm at mattdm.org Boston University Linux ------> From sundaram at redhat.com Sat Dec 10 17:29:37 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Sat, 10 Dec 2005 22:59:37 +0530 Subject: yum clean bug In-Reply-To: <20051210172444.GA21442@jadzia.bu.edu> References: <1134203874.2183.40.camel@cutter> <200512100911.24676.lists@wilsonet.com> <20051210172444.GA21442@jadzia.bu.edu> Message-ID: <439B1081.3030300@redhat.com> Matthew Miller wrote: >On Sat, Dec 10, 2005 at 09:11:24AM -0800, Jarod Wilson wrote: > > >>How 'bout adding a config option to yum.conf? Default setting for the >>"cleanall" option could be "enabled-only", users could switch that to >>"nuke-everything", or something along those lines. Seems like a reasonable >>compromise that gives both sides of the fence what they want, no? >> >> > >I think that makes it worse, since you'd never know what clean all does on a >given machine without checking the config. > > > Yep. Configuration options that change command behavior like this are just plain evil. It will make miserable any attempts to debug problems. If you need more fiddling power add them to yum-utils. regards rahul From ivazquez at ivazquez.net Sat Dec 10 17:41:26 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sat, 10 Dec 2005 12:41:26 -0500 Subject: Dependency problem with fc4 updates? In-Reply-To: References: Message-ID: <1134236486.3672.3.camel@ignacio.lan> On Sat, 2005-12-10 at 11:58 -0500, Neal Becker wrote: > Looks like gsm update is missing? And if gsm were part of Core or Extras then you might have a point. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From ndbecker2 at gmail.com Sat Dec 10 18:35:08 2005 From: ndbecker2 at gmail.com (Neal Becker) Date: Sat, 10 Dec 2005 13:35:08 -0500 Subject: Dependency problem with fc4 updates? References: <1134236486.3672.3.camel@ignacio.lan> Message-ID: Ignacio Vazquez-Abrams wrote: > On Sat, 2005-12-10 at 11:58 -0500, Neal Becker wrote: >> Looks like gsm update is missing? > > And if gsm were part of Core or Extras then you might have a point. > Sorry, then. I assumed it was part of core or extras, because as you could see in the message, it didn't have a suffix on the package. From jspaleta at gmail.com Sat Dec 10 18:47:44 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 10 Dec 2005 13:47:44 -0500 Subject: Dependency problem with fc4 updates? In-Reply-To: References: <1134236486.3672.3.camel@ignacio.lan> Message-ID: <604aa7910512101047g3b97815cl35a47a04688c5366@mail.gmail.com> On 12/10/05, Neal Becker wrote: > Sorry, then. I assumed it was part of core or extras, because as you could > see in the message, it didn't have a suffix on the package. There is no requirement that 3rd parties provide a suffix. Even if there were such a requirement it would be impossible to enforce. If this sort of thing is going to continue to confuse you, I suggest you check the Vendor/Packager tag and the gpg signature for that gsm-devel package to determine who made that package, and contact the packager and tell them that you prefer it if they continued to use a suffix in the release field. -jef From tmus at tmus.dk Sat Dec 10 20:33:05 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Sat, 10 Dec 2005 21:33:05 +0100 Subject: yum clean bug In-Reply-To: References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> Message-ID: Panu Matilainen wrote: > > This is precisely the reason I dislike the current behavior - if I ask > yum to "clean all" I really expect it to clean ALL of the cache and not > leave old junk from disabled repos around, eating disk space. > >> If this is really the way we want it to act, please clearly document >> that we need to add --enablerepo=* to clean disabled repos. > > I guess can live with that, it just feels rather counterintuitive to me > to have to mess with repo settings to clean cache data. If somebody can > come up with a real, sane usage scenario why leaving disabled repos > alone on clean operations is a good idea it might help making it feel a > bit less odd. :) > Problem with the yum --enablerepo=\* clean all approach as things are today, is that non-defined repos are NOT cleaned from this. I can appreciate that people are using repo disabling for various things where cleaning the repo might not be desirable, so I guess i can live with the current behaviour for disabled repos. Are there any good reason for not nuking non-existing yum repo cache entries? Apart from the fact that somebody else might have put data in there for something else? I mean /var/cache/yum, is still considered yum's, right? So deleting data that somebody put in there manually should not be a violation of anything, right? anyone? /Thomas From jdieter99 at gmx.net Sat Dec 10 22:57:40 2005 From: jdieter99 at gmx.net (Jonathan Dieter) Date: Sun, 11 Dec 2005 00:57:40 +0200 Subject: RPM Patching In-Reply-To: <1cef3e950512100656h2dd3e674s2043c9b3c21bfabe@mail.gmail.com> References: <439AEB31.6030502@gmx.net> <1cef3e950512100656h2dd3e674s2043c9b3c21bfabe@mail.gmail.com> Message-ID: <439B5D64.7070409@gmx.net> I've looked at both your code and Michael's and I'm very impressed. You've gone much further than I have in the whole distribution side of things, and Michael's code for extracting and compressing the code is much cleaner than mine (I didn't know about the rpmlib functions). There's really not much of anything I can add except the fact that I'm dealing with the RPMs on a file by file basis, which means you don't necessarily have to have the original RPM when applying the patch. You just have to have installed it on your system. Anyhow, I don't know how likely that scenario is, but if you want to look at my code, it's at http://www.lesbg.com/jdieter/rpmpatch/files. I've included rpms, source rpms, and tar.gz's, so take what you need. cx_bsdiff is not my creation at all and is available from SourceForge. rpmpatch is the actual program that does the patching, but I realize that name is already taken by some other utility. I will switch names if anything comes of this. If I was going to take this any further, I would switch to edelta (thanks Florian) as it seems to give equivalant compression to bsdiff at much less memory cost, and I would probably convert Michael's archive extraction code to Python and use it instead of my ugly rpmgzip module. But, like I said, there's not much point in using my system if we figure most people keep their RPMs handy. Jonathan From lists at wilsonet.com Sun Dec 11 08:44:49 2005 From: lists at wilsonet.com (Jarod Wilson) Date: Sun, 11 Dec 2005 00:44:49 -0800 Subject: yum clean bug In-Reply-To: <439B1081.3030300@redhat.com> References: <20051210172444.GA21442@jadzia.bu.edu> <439B1081.3030300@redhat.com> Message-ID: <200512110044.49762.lists@wilsonet.com> On Saturday 10 December 2005 09:29, Rahul Sundaram wrote: > Matthew Miller wrote: > >On Sat, Dec 10, 2005 at 09:11:24AM -0800, Jarod Wilson wrote: > >>How 'bout adding a config option to yum.conf? Default setting for the > >>"cleanall" option could be "enabled-only", users could switch that to > >>"nuke-everything", or something along those lines. Seems like a > >> reasonable compromise that gives both sides of the fence what they want, > >> no? > > > >I think that makes it worse, since you'd never know what clean all does on > > a given machine without checking the config. > > Yep. Configuration options that change command behavior like this are > just plain evil. It will make miserable any attempts to debug problems. Good point. > If you need more fiddling power add them to yum-utils. I don't need it myself, was just throwing it out there. Until reading this thread, I didn't even realize there was a distinction to make on what "yum clean all" did. Never even thought about it, I'd always just assumed it actually did clean all defined repos (including the disabled ones). I can see both sides of the argument on this one, but I really don't care which one is the default. Knowing is enough, and I'm certainly capable of removing things by hand if I really want all cached data gone. -- Jarod Wilson jarod at wilsonet.com -- Jarod Wilson jarod at wilsonet.com From cybernet at interia.pl Sun Dec 11 11:24:58 2005 From: cybernet at interia.pl (cybernet at interia.pl) Date: Sun, 11 Dec 2005 12:24:58 +0100 Subject: "yum --partial" feature as a bash line Message-ID: <439C0C8A.9090002@interia.pl> Since the yum "bug" topic flooded the mailing list, this is a new post. A few days ago someone proposed a "yum --partial" feature in order to have partial updates instead of no updates - e.g if eclipse is broken, then why shouldn't httpd get updated? Heres a quick "answer" : # get a list of items # remove 4 lines from top (tac/head/tac) # try to update one item at a time for k in `yum list updates | awk '{ print $1 }' | tac | head -n-4 | tac`; do yum -y update $k; done Obviously this isn't too nice, but if someone has a better idea, this would allow fedora devel/test users to make automatic partial updates when dependencies are broken (quite often with the devel repositories). I don't expect a feature like this to be implemented in yum, since in the real world, we don't have broken dependencies (theoretically). Or should I write a yum plugin ... ? ------------------------------------------------------------------------ Szukasz pracy? Szukamy pracownikow: dziennikarzy, webmasterow, specjalisty ds. badan, promotion managera, administratorow baz danych, programistow Windows i wielu innych! >>> http://link.interia.pl/f18e6 From sundaram at redhat.com Sun Dec 11 11:34:46 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Sun, 11 Dec 2005 17:04:46 +0530 Subject: "yum --partial" feature as a bash line In-Reply-To: <439C0C8A.9090002@interia.pl> References: <439C0C8A.9090002@interia.pl> Message-ID: <439C0ED6.5070506@redhat.com> cybernet at interia.pl wrote: > Since the yum "bug" topic flooded the mailing list, this is a new > post. A few days ago someone proposed a "yum --partial" feature in > order to have partial updates instead of no updates - e.g if eclipse > is broken, then why shouldn't httpd get updated? > > Heres a quick "answer" : > > # get a list of items > # remove 4 lines from top (tac/head/tac) > # try to update one item at a time > for k in `yum list updates | awk '{ print $1 }' | tac | head -n-4 | > tac`; do yum -y update > $k; done This has been added long back to http://fedoraproject.org/wiki/Tools/yum regards Rahul From paul at city-fan.org Sun Dec 11 11:46:56 2005 From: paul at city-fan.org (Paul Howarth) Date: Sun, 11 Dec 2005 11:46:56 +0000 Subject: yum clean bug In-Reply-To: References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> Message-ID: <1134301616.12691.24.camel@laurel.intra.city-fan.org> On Sat, 2005-12-10 at 21:33 +0100, Thomas M Steenholdt wrote: > Panu Matilainen wrote: > > > > This is precisely the reason I dislike the current behavior - if I ask > > yum to "clean all" I really expect it to clean ALL of the cache and not > > leave old junk from disabled repos around, eating disk space. > > > >> If this is really the way we want it to act, please clearly document > >> that we need to add --enablerepo=* to clean disabled repos. > > > > I guess can live with that, it just feels rather counterintuitive to me > > to have to mess with repo settings to clean cache data. If somebody can > > come up with a real, sane usage scenario why leaving disabled repos > > alone on clean operations is a good idea it might help making it feel a > > bit less odd. :) > > > > Problem with the yum --enablerepo=\* clean all approach as things are > today, is that non-defined repos are NOT cleaned from this. > > I can appreciate that people are using repo disabling for various things > where cleaning the repo might not be desirable, so I guess i can live > with the current behaviour for disabled repos. > > Are there any good reason for not nuking non-existing yum repo cache > entries? Apart from the fact that somebody else might have put data in > there for something else? I mean /var/cache/yum, is still considered > yum's, right? So deleting data that somebody put in there manually > should not be a violation of anything, right? It'll break setups where multiple machines are sharing a cache and not using exactly the same set of repos. Paul. -- Paul Howarth From buildsys at redhat.com Sun Dec 11 11:54:26 2005 From: buildsys at redhat.com (Build System) Date: Sun, 11 Dec 2005 06:54:26 -0500 Subject: rawhide report: 20051211 changes Message-ID: <200512111154.jBBBsPdT013749@porkchop.devel.redhat.com> Updated Packages: HelixPlayer-1:1.0.6-1.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - 1:1.0.6-1 - rebuilt a2ps-4.13b-48.1.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt acl-2.2.32-2.1.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt acpid-1.0.4-1.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt adaptx-0:0.9.6-1jpp_2fc.1.1 --------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt adjtimex-1.20-1.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt alchemist-1.0.36-1.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt alsa-utils-1.0.10rf-1.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt am-utils-5:6.1.3-1.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt amanda-2.4.5p1-2.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt anaconda-10.90.16-1 ------------------- * Sat Dec 10 2005 Jeremy Katz - 10.90.16-1 - Ensure upgrades to depsolve and remove db locks (pnasrat) - Tweak for improved and sortable groups/categories - Put back basic text-mode package selection (#175443) anacron-2.3-34.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt ant-0:1.6.5-1jpp_1fc.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt anthy-7100b-2.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt antlr-0:2.7.4-2jpp_4fc.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt apmd-1:3.2.2-3.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt aqbanking-1.0.4beta-2.1 ----------------------- aqhbci-1.0.2beta-2.1 -------------------- arptables_jf-0:0.0.8-6.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt arts-8:1.5.0-0.1.rc2.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt asm-0:1.5.3-1jpp_1fc.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt aspell-af-50:0.50-4.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt aspell-bg-50:0.50-11.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt aspell-br-50:0.50-4.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt aspell-ca-50:0.50-4.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt aspell-cy-50:0.50-4.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt aspell-da-50:0.50-12.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt aspell-de-50:0.50-11.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt aspell-el-50:0.50-4.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt aspell-en-50:6.0-1.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt aspell-es-50:0.50-13.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt aspell-fo-50:0.51-4.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt aspell-fr-50:0.50-9.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt aspell-ga-50:0.50-4.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt aspell-gd-50:0.50-4.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt aspell-gl-50:0.50-4.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt aspell-hr-50:0.51-4.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt aspell-id-50:0.50.1-4.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt aspell-is-50:0.51.1-2.1 ----------------------- aspell-nl-50:0.50-7.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt aspell-no-50:0.50.1-9.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt aspell-pt-50:0.50-10.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt aspell-ru-50:0.99f7-2.1 ----------------------- aspell-sv-50:0.50-8.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt at-spi-1.6.6-2.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt * Mon Oct 31 2005 Matthias Clasen 1.6.6-2 - Switch requires to modular X atk-1.10.3-1.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt attr-2.4.24-2.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt audit-1.1.2-1.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt authconfig-5.0.4-1.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt authd-1.4.3-6.devel.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt autoconf-2.59-5.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt autoconf213-2.13-10.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt autofs-1:4.1.4-14.1.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt automake-1.9.6-1.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt automake14-1.4p6-12.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt automake16-1.6.3-5.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt automake17-1.7.9-6.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt autorun-3.17-1.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt avahi-0.6.1-2.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt awesfx-0.5.0d-3.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt axis-0:1.2.1-1jpp_1fc.1.1 ------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt basesystem-8.0-5.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt bash-3.0-40.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt bc-1.06-19.1 ------------ * Fri Dec 09 2005 Jesse Keating - rebuilt * Mon Nov 21 2005 Thomas Woerner 1.06-19 - fixed rpm macro usage in chengelog (#137800) * Wed Jan 12 2005 Tim Waugh 1.06-18 - Rebuilt for new readline. bcel-0:5.1-1jpp_4fc.1.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt * Tue Nov 08 2005 Vadim Nasardinov - 0:5.1-1jpp_4fc - Converted from ISO-8859-1 to UTF-8 beecrypt-4.1.2-9.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt bg5ps-1.3.0-22.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt bind-28:9.3.2rc1-1.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt binutils-2.16.91.0.3-1.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt bison-2.1-1.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt bitmap-fonts-0.3-5.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt bitstream-vera-fonts-1.10-5.1 ----------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt bluez-hcidump-1.27-1.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt bluez-libs-2.22-1.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt bogl-0:0.1.18-11.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt bootparamd-0.17-23.devel.1 -------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt booty-0.61-1.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt bridge-utils-1.0.4-6.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt brltty-3.2-10.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt bsf-0:2.3.0-6jpp_2fc.1.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt bsh-0:1.3.0-5jpp_1fc.1.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt bug-buddy-1:2.12.1-2.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt busybox-1:1.01-2.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt byacc-1.9-29.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt bzip2-1.0.3-2.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt caching-nameserver-7.3-3.1 -------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt cadaver-0.22.2-3.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt castor-0:0.9.5-1jpp_1fc.1.1 --------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt ccs-1.0.2-3.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt cdparanoia-alpha9.8-26.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt cdrdao-1.2.0-1.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt cdrtools-8:2.01.01.0.a03-1.1 ---------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt checkpolicy-1.28-1.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt chkconfig-1.3.25-1.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt chkfontpath-1.10.0-4.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt ckermit-8.0.211-4.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt classpathx-jaf-0:1.0-2jpp_3fc.1 ------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt classpathx-mail-0:1.0-4jpp_3fc.1 -------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt cleanfeed-0.95.7b-21.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt compat-db-4.2.52-3.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt compat-readline43-4.3-2.1 ------------------------- compat-slang-1.4.9-27.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt comps-extras-10.3-1.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt concurrent-0:1.3.2-2jpp_1fc.1 ----------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt control-center-1:2.13.2-1.1 --------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt coreutils-5.93-4.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt * Fri Dec 02 2005 Tim Waugh - Parametrize SELinux (bug #174067). - Fix runuser.pamd (bug #173807). cpio-2.6-11.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt cracklib-2.8.6-1.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt createrepo-0.4.3-5.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt crontabs-1.10-7.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt cryptix-0:3.2.0-4jpp_2fc.1.1 ---------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt * Tue Jun 21 2005 Gary Benson 3.2.0-4jpp_2fc - Remove jarfile from the tarball. * Fri Jan 21 2005 Gary Benson 3.2.0-4jpp_1fc - Build into Fedora. cryptix-asn1-0:20011119-4jpp_2fc.1.1 ------------------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt crypto-utils-2.2-9.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt cryptsetup-luks-1.0.1-4.1 ------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt ctags-5.5.4-4.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt cups-1:1.1.23-26.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt curl-7.15.1-1.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt cvs-1.11.21-1.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt cyrus-sasl-2.1.21-8.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt dasher-3.2.18-3 --------------- * Sun Dec 11 2005 Matthias Clasen - Add -Wl,--export-dynamic, - Make compile with gcc 4.1 * Fri Dec 09 2005 Jesse Keating - rebuilt db4-4.3.29-1.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt dcraw-0.0.20050227-1.1 ---------------------- ddd-3.3.11-4.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt dejagnu-1:1.4.4-4.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt desktop-file-utils-0.10-3.1 --------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt devhelp-0.10-6.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt dhcdbd-1.11-1.FC5.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt dhcpv6-0.10-15.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt dialog-1.0.20051107-1.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt diffstat-1.41-1.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt diffutils-2.8.1-15.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt distcache-1.4.5-12.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt dmraid-1.0.0.rc9-FC5_4.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt docbook-dtds-1.0-29.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt docbook-simple-1.0-2.1 ---------------------- docbook-slides-3.3.1-2.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt docbook-style-dsssl-1.79-2.1 ---------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt docbook-style-xsl-1.69.1-1.1 ---------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt dos2unix-3.1-24.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt dovecot-0.99.14-10.fc5.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt dtach-0.7-1.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt dump-0.4b40-5.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt dvd+rw-tools-5.21.4.10.8-6.1 ---------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt dvgrab-2.0-1.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt e2fsprogs-1.38-2.1.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt ed-0.2-38.1 ----------- * Fri Dec 09 2005 Jesse Keating - rebuilt eel2-2.13.2-1.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt efax-0.9-26.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt eject-2.1.2-1.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt elfutils-0.118-1.1.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt elinks-0.10.6-2.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt emacs-21.4-10.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt emacspeak-21.0-2.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt enscript-1.6.1-31.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt eog-2.13.2-1.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt epic-4:2.2-2.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt epiphany-1.9.2-1.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt eruby-1.0.5-5.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt esound-1:0.2.36-2.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt ethereal-0.10.13-6.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt ethtool-3-1.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt evince-0.4.0-3.1 ---------------- * Fri Dec 09 2005 Jesse Keating - 0.4.0-3.1 - rebuilt evolution-connector-2.5.2-1.1 ----------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt evolution-webcal-2.4.1-1.1 -------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt expat-1.95.8-6.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt fbset-2.1-20.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt fedora-logos-1.1.34-1.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt file-roller-2.13.1-1.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt firstboot-1.3.55-1.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt fonts-ISO8859-2-1.0-16.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt fonts-KOI8-R-1.0-9.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt fonts-arabic-1.5-4.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt fonts-chinese-3.02-4.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt fonts-hebrew-0.100-4.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt fonts-indic-1.10-2.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt fonts-japanese-0.20050222-11.1 ------------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt fonts-korean-1.0.11-9.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt fractal-0:2.2-2jpp_1fc.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt freetype-2.1.10-5.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt fribidi-0.10.4-8.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt ftp-0.17-31.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt ghostscript-fonts-5.50-13.1 --------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gif89encoder-0:0.90-0.b.1jpp_1fc.1 ---------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gimp-data-extras-2.0.1-1.1 -------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gimp-help-2-0.1.0.9.1.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt glib2-2.9.1-1 ------------- * Sat Dec 10 2005 Matthias Clasen - 2.9.1-1 - New upstream version gnome-applets-1:2.12.2-1.1 -------------------------- * Fri Dec 09 2005 Jesse Keating 2.12.2-1.1 - rebuilt gnome-audio-2.0.0-3.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-doc-utils-0.5.1-1.1 ------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-icon-theme-2.13.2-1.1 --------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-power-manager-0.3.1-2.1 ----------------------------- * Fri Dec 09 2005 Jesse Keating - 0.3.1-2.1 - rebuilt gnome-python2-2.12.1-1.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - 2.12.1-1.1 - rebuilt gnome-python2-extras-2.12.1-7.1 ------------------------------- * Fri Dec 09 2005 Jesse Keating - 2.12.1-7.1 - rebuilt gnome-screensaver-0.0.20-2.1 ---------------------------- * Fri Dec 09 2005 Jesse Keating - 0.0.20-2.1 - rebuilt gnome-utils-1:2.13.2-4.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-vfs2-2.13.1-1.1 --------------------- * Fri Dec 09 2005 Jesse Keating - 2.13.1-1.1 - rebuilt gnome-volume-manager-1.5.4-1.1 ------------------------------ * Fri Dec 09 2005 Jesse Keating - 1.5.4-1.1 - rebuilt gstreamer-0.8.11-2.1 -------------------- * Fri Dec 09 2005 Jesse Keating 0.8.11-2.1 - rebuilt * Tue Nov 15 2005 Florian La Roche 0.8.11-2 - silence post script gstreamer-plugins-0.8.11-1.1 ---------------------------- * Fri Dec 09 2005 Jesse Keating - 0.8.11-1.1 - rebuilt gthumb-2.7.1-1.1 ---------------- * Fri Dec 09 2005 Jesse Keating - 2.7.1-1.1 - rebuilt gtk2-2.8.9-1.1 -------------- * Sat Dec 10 2005 Matthias Clasen 2.8.9-1 - Update to 2.8.9 * Fri Dec 09 2005 Jesse Keating - rebuilt * Mon Nov 28 2005 Matthias Clasen 2.8.8-1 - Update to 2.8.8 gtk2-engines-2.7.0-2 -------------------- * Sun Dec 11 2005 Matthias Clasen 2.7.0-2 - Backport some fixes from upstream * Fri Dec 09 2005 Jesse Keating - rebuilt hal-0.5.5.1-2.1 --------------- * Fri Dec 09 2005 Jesse Keating - 0.5.5.1-2.1 - rebuilt * Thu Dec 01 2005 John (J5) Palmieri - 0.5.5.1-2 - Rebuild for dbus 0.60 * Wed Nov 16 2005 John (J5) Palmieri - 0.5.5.1-1 - Update to latest upstream version hal-cups-utils-0.5.4-2.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - 0.5.4-2.1 - rebuilt krb5-auth-dialog-0.5-2.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - 0.5-2.1 - rebuilt pup-0.1.9-1 ----------- * Sat Dec 10 2005 Jeremy Katz - 0.1.9-1 - prompt for a reboot on packages which should do so - give info on dependencies that are pulled in pygtk2-2.8.2-2.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt redhat-artwork-0.131-1.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt yum-2.5.0-0.20051210 -------------------- * Sat Dec 10 2005 Jeremy Katz - 2.5.0-0.20051210 - update to newer CVS * Fri Dec 09 2005 Jesse Keating - rebuilt Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 anaconda - 10.90.16-1.i386 requires anaconda-help carol - 1.8.9.3-1jpp_6fc.i386 requires libgcj.so.6 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel = 0:2.6.14-1.1696_FC5 cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5smp cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 eclipse-bugzilla - 1:0.1.1_fc-5.i386 requires libgcj.so.6 eclipse-cdt - 1:3.0.1-1jpp_1fc.i386 requires libgcj.so.6 eclipse-changelog - 1:2.0.1_fc-22.i386 requires libgcj.so.6 eclipse-ecj - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-jdt - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-pde - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-platform - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-pydev - 1:0.9.3_fc-12.i386 requires libgcj.so.6 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel = 0:2.6.14-1.1696_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 gnu-crypto - 2.0.1-1jpp_8fc.i386 requires libgcj.so.6 gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.i386 requires libgcj.so.6 gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.i386 requires libgcj.so.6 jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jotm - 2.0.5-1jpp_3fc.i386 requires libgcj.so.6 jsch - 0.1.18-1jpp_2fc.i386 requires libgcj.so.6 libglade-java - 2.12.1-2.i386 requires libgcj.so.6 libgnome-java - 2.12.1-2.i386 requires libgcj.so.6 libgtk-java - 2.8.1-1.i386 requires libgcj.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.i386 requires libgcjawt.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 libvte-java - 0.11.11-6.i386 requires libgcj.so.6 lucene - 1.4.3-1jpp_7fc.i386 requires libgcj.so.6 lucene-demo - 1.4.3-1jpp_7fc.i386 requires libgcj.so.6 monolog - 1.8.6-1jpp_5fc.i386 requires libgcj.so.6 mx4j - 1:3.0.1-1jpp_5fc.i386 requires libgcj.so.6 nanoxml - 2.2.3-3jpp_3fc.i386 requires libgcj.so.6 nanoxml-lite - 2.2.3-3jpp_3fc.i386 requires libgcj.so.6 oldkilim - 1.1.3-2jpp_3fc.i386 requires libgcj.so.6 openoffice.org-core - 1:2.0.1-143.1.2.i386 requires libgcjawt.so.6 openoffice.org-core - 1:2.0.1-143.1.2.i386 requires libgcj.so.6 p6spy - 1.3-2jpp_3fc.i386 requires libgcj.so.6 regexp - 1.3-2jpp_3fc.i386 requires libgcj.so.6 struts - 1.2.4-2jpp_3fc.i386 requires libgcj.so.6 struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.i386 requires libgcj.so.6 systemtap - 0.5-2.i386 requires libdw.so.1(ELFUTILS_0.116) tetex-xdvi - 3.0-11.i386 requires libXm.so.3 tomcat5 - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 tomcat5-admin-webapps - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 tomcat5-jasper - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 tomcat5-webapps - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 xalan-j2 - 2.6.0-3jpp_4fc.i386 requires libgcj.so.6 xalan-j2-demo - 2.6.0-3jpp_4fc.i386 requires libgcj.so.6 xalan-j2-xsltc - 2.6.0-3jpp_4fc.i386 requires libgcj.so.6 xerces-j2 - 2.6.2-5jpp_2fc.i386 requires libgcj.so.6 xerces-j2-demo - 2.6.2-5jpp_2fc.i386 requires libgcj.so.6 xml-commons-apis - 1.0-0.b2.7jpp_3fc.i386 requires libgcj.so.6 xml-commons-which - 1.0-0.b2.7jpp_3fc.i386 requires libgcj.so.6 xpdf - 1:3.01-5.i386 requires libXm.so.3 Broken deps for ia64 ---------------------------------------------------------- anaconda - 10.90.16-1.ia64 requires anaconda-help carol - 1.8.9.3-1jpp_6fc.ia64 requires libgcj.so.6()(64bit) gnu-crypto - 2.0.1-1jpp_8fc.ia64 requires libgcj.so.6()(64bit) gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.ia64 requires libgcj.so.6()(64bit) gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.ia64 requires libgcj.so.6()(64bit) jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) jotm - 2.0.5-1jpp_3fc.ia64 requires libgcj.so.6()(64bit) jsch - 0.1.18-1jpp_2fc.ia64 requires libgcj.so.6()(64bit) libglade-java - 2.12.1-2.ia64 requires libgcj.so.6()(64bit) libgnome-java - 2.12.1-2.ia64 requires libgcj.so.6()(64bit) libgtk-java - 2.8.1-1.ia64 requires libgcj.so.6()(64bit) libsetrans - 0.1.11-2.ia64 requires libc.so.6(GLIBC_2.3.4) libsetrans - 0.1.11-2.ia64 requires libc.so.6(GLIBC_2.4) libsetrans - 0.1.11-2.ia64 requires libc.so.6(GLIBC_2.1) libsetrans - 0.1.11-2.ia64 requires libc.so.6(GLIBC_2.0) libsetrans - 0.1.11-2.ia64 requires libdl.so.2 libsetrans - 0.1.11-2.ia64 requires libc.so.6(GLIBC_2.1.3) libsetrans - 0.1.11-2.ia64 requires libc.so.6(GLIBC_2.3) libsetrans - 0.1.11-2.ia64 requires libc.so.6 libsetrans - 0.1.11-2.ia64 requires libselinux.so.1 libvte-java - 0.11.11-6.ia64 requires libgcj.so.6()(64bit) lucene - 1.4.3-1jpp_7fc.ia64 requires libgcj.so.6()(64bit) lucene-demo - 1.4.3-1jpp_7fc.ia64 requires libgcj.so.6()(64bit) monolog - 1.8.6-1jpp_5fc.ia64 requires libgcj.so.6()(64bit) mx4j - 1:3.0.1-1jpp_5fc.ia64 requires libgcj.so.6()(64bit) nanoxml - 2.2.3-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) nanoxml-lite - 2.2.3-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) oldkilim - 1.1.3-2jpp_3fc.ia64 requires libgcj.so.6()(64bit) p6spy - 1.3-2jpp_3fc.ia64 requires libgcj.so.6()(64bit) regexp - 1.3-2jpp_3fc.ia64 requires libgcj.so.6()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs struts - 1.2.4-2jpp_3fc.ia64 requires libgcj.so.6()(64bit) struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.ia64 requires libgcj.so.6()(64bit) systemtap - 0.5-2.ia64 requires libdw.so.1(ELFUTILS_0.116)(64bit) tetex-xdvi - 3.0-11.ia64 requires libXm.so.3()(64bit) tomcat5 - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) tomcat5-admin-webapps - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) tomcat5-jasper - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) tomcat5-webapps - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) xalan-j2 - 2.6.0-3jpp_4fc.ia64 requires libgcj.so.6()(64bit) xalan-j2-demo - 2.6.0-3jpp_4fc.ia64 requires libgcj.so.6()(64bit) xalan-j2-xsltc - 2.6.0-3jpp_4fc.ia64 requires libgcj.so.6()(64bit) xerces-j2 - 2.6.2-5jpp_2fc.ia64 requires libgcj.so.6()(64bit) xerces-j2-demo - 2.6.2-5jpp_2fc.ia64 requires libgcj.so.6()(64bit) xml-commons-apis - 1.0-0.b2.7jpp_3fc.ia64 requires libgcj.so.6()(64bit) xml-commons-which - 1.0-0.b2.7jpp_3fc.ia64 requires libgcj.so.6()(64bit) xpdf - 1:3.01-5.ia64 requires libXm.so.3()(64bit) Broken deps for ppc ---------------------------------------------------------- anaconda - 10.90.16-1.ppc requires anaconda-help carol - 1.8.9.3-1jpp_6fc.ppc requires libgcj.so.6 cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 eclipse-bugzilla - 1:0.1.1_fc-5.ppc requires libgcj.so.6 eclipse-cdt - 1:3.0.1-1jpp_1fc.ppc requires libgcj.so.6 eclipse-changelog - 1:2.0.1_fc-22.ppc requires libgcj.so.6 eclipse-ecj - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-jdt - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-pde - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-platform - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-pydev - 1:0.9.3_fc-12.ppc requires libgcj.so.6 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 gnu-crypto - 2.0.1-1jpp_8fc.ppc requires libgcj.so.6 gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.ppc requires libgcj.so.6 gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.ppc requires libgcj.so.6 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jotm - 2.0.5-1jpp_3fc.ppc requires libgcj.so.6 jsch - 0.1.18-1jpp_2fc.ppc requires libgcj.so.6 libglade-java - 2.12.1-2.ppc requires libgcj.so.6 libgnome-java - 2.12.1-2.ppc requires libgcj.so.6 libgtk-java - 2.8.1-1.ppc requires libgcj.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.ppc requires libgcjawt.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 libvte-java - 0.11.11-6.ppc requires libgcj.so.6 lucene - 1.4.3-1jpp_7fc.ppc requires libgcj.so.6 lucene-demo - 1.4.3-1jpp_7fc.ppc requires libgcj.so.6 monolog - 1.8.6-1jpp_5fc.ppc requires libgcj.so.6 mx4j - 1:3.0.1-1jpp_5fc.ppc requires libgcj.so.6 nanoxml - 2.2.3-3jpp_3fc.ppc requires libgcj.so.6 nanoxml-lite - 2.2.3-3jpp_3fc.ppc requires libgcj.so.6 oldkilim - 1.1.3-2jpp_3fc.ppc requires libgcj.so.6 openoffice.org-core - 1:2.0.1-143.1.2.ppc requires libgcjawt.so.6 openoffice.org-core - 1:2.0.1-143.1.2.ppc requires libgcj.so.6 p6spy - 1.3-2jpp_3fc.ppc requires libgcj.so.6 regexp - 1.3-2jpp_3fc.ppc requires libgcj.so.6 struts - 1.2.4-2jpp_3fc.ppc requires libgcj.so.6 struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.ppc requires libgcj.so.6 systemtap - 0.5-2.ppc requires libdw.so.1(ELFUTILS_0.116) tetex-xdvi - 3.0-11.ppc requires libXm.so.3 tomcat5 - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 tomcat5-admin-webapps - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 tomcat5-jasper - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 tomcat5-webapps - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 xalan-j2 - 2.6.0-3jpp_4fc.ppc requires libgcj.so.6 xalan-j2-demo - 2.6.0-3jpp_4fc.ppc requires libgcj.so.6 xalan-j2-xsltc - 2.6.0-3jpp_4fc.ppc requires libgcj.so.6 xerces-j2 - 2.6.2-5jpp_2fc.ppc requires libgcj.so.6 xerces-j2-demo - 2.6.2-5jpp_2fc.ppc requires libgcj.so.6 xml-commons-apis - 1.0-0.b2.7jpp_3fc.ppc requires libgcj.so.6 xml-commons-which - 1.0-0.b2.7jpp_3fc.ppc requires libgcj.so.6 xpdf - 1:3.01-5.ppc requires libXm.so.3 Broken deps for ppc64 ---------------------------------------------------------- anaconda - 10.90.16-1.ppc64 requires anaconda-help carol - 1.8.9.3-1jpp_6fc.ppc64 requires libgcj.so.6()(64bit) cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 gnu-crypto - 2.0.1-1jpp_8fc.ppc64 requires libgcj.so.6()(64bit) gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.ppc64 requires libgcj.so.6()(64bit) gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.ppc64 requires libgcj.so.6()(64bit) jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) jotm - 2.0.5-1jpp_3fc.ppc64 requires libgcj.so.6()(64bit) jsch - 0.1.18-1jpp_2fc.ppc64 requires libgcj.so.6()(64bit) libglade-java - 2.12.1-2.ppc64 requires libgcj.so.6()(64bit) libgnome-java - 2.12.1-2.ppc64 requires libgcj.so.6()(64bit) libgtk-java - 2.8.1-1.ppc64 requires libgcj.so.6()(64bit) libsetrans - 0.1.11-2.ppc64 requires libc.so.6(GLIBC_2.3.4) libsetrans - 0.1.11-2.ppc64 requires libc.so.6(GLIBC_2.4) libsetrans - 0.1.11-2.ppc64 requires libc.so.6(GLIBC_2.1) libsetrans - 0.1.11-2.ppc64 requires libc.so.6(GLIBC_2.0) libsetrans - 0.1.11-2.ppc64 requires libdl.so.2 libsetrans - 0.1.11-2.ppc64 requires libc.so.6(GLIBC_2.1.3) libsetrans - 0.1.11-2.ppc64 requires libc.so.6(GLIBC_2.3) libsetrans - 0.1.11-2.ppc64 requires libc.so.6 libsetrans - 0.1.11-2.ppc64 requires libselinux.so.1 libvte-java - 0.11.11-6.ppc64 requires libgcj.so.6()(64bit) lucene - 1.4.3-1jpp_7fc.ppc64 requires libgcj.so.6()(64bit) lucene-demo - 1.4.3-1jpp_7fc.ppc64 requires libgcj.so.6()(64bit) monolog - 1.8.6-1jpp_5fc.ppc64 requires libgcj.so.6()(64bit) mx4j - 1:3.0.1-1jpp_5fc.ppc64 requires libgcj.so.6()(64bit) nanoxml - 2.2.3-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) nanoxml-lite - 2.2.3-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) oldkilim - 1.1.3-2jpp_3fc.ppc64 requires libgcj.so.6()(64bit) p6spy - 1.3-2jpp_3fc.ppc64 requires libgcj.so.6()(64bit) regexp - 1.3-2jpp_3fc.ppc64 requires libgcj.so.6()(64bit) struts - 1.2.4-2jpp_3fc.ppc64 requires libgcj.so.6()(64bit) struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.ppc64 requires libgcj.so.6()(64bit) tetex-xdvi - 3.0-11.ppc64 requires libXm.so.3()(64bit) tomcat5 - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) tomcat5-admin-webapps - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) tomcat5-jasper - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) tomcat5-webapps - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) xalan-j2 - 2.6.0-3jpp_4fc.ppc64 requires libgcj.so.6()(64bit) xalan-j2-demo - 2.6.0-3jpp_4fc.ppc64 requires libgcj.so.6()(64bit) xalan-j2-xsltc - 2.6.0-3jpp_4fc.ppc64 requires libgcj.so.6()(64bit) xerces-j2 - 2.6.2-5jpp_2fc.ppc64 requires libgcj.so.6()(64bit) xerces-j2-demo - 2.6.2-5jpp_2fc.ppc64 requires libgcj.so.6()(64bit) xml-commons-apis - 1.0-0.b2.7jpp_3fc.ppc64 requires libgcj.so.6()(64bit) xml-commons-which - 1.0-0.b2.7jpp_3fc.ppc64 requires libgcj.so.6()(64bit) xpdf - 1:3.01-5.ppc64 requires libXm.so.3()(64bit) Broken deps for s390 ---------------------------------------------------------- anaconda - 10.90.16-1.s390 requires anaconda-help carol - 1.8.9.3-1jpp_6fc.s390 requires libgcj.so.6 gnu-crypto - 2.0.1-1jpp_8fc.s390 requires libgcj.so.6 gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.s390 requires libgcj.so.6 gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.s390 requires libgcj.so.6 jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jotm - 2.0.5-1jpp_3fc.s390 requires libgcj.so.6 jsch - 0.1.18-1jpp_2fc.s390 requires libgcj.so.6 libglade-java - 2.12.1-2.s390 requires libgcj.so.6 libgnome-java - 2.12.1-2.s390 requires libgcj.so.6 libgtk-java - 2.8.1-1.s390 requires libgcj.so.6 libvte-java - 0.11.11-6.s390 requires libgcj.so.6 lucene - 1.4.3-1jpp_7fc.s390 requires libgcj.so.6 lucene-demo - 1.4.3-1jpp_7fc.s390 requires libgcj.so.6 monolog - 1.8.6-1jpp_5fc.s390 requires libgcj.so.6 mx4j - 1:3.0.1-1jpp_5fc.s390 requires libgcj.so.6 nanoxml - 2.2.3-3jpp_3fc.s390 requires libgcj.so.6 nanoxml-lite - 2.2.3-3jpp_3fc.s390 requires libgcj.so.6 oldkilim - 1.1.3-2jpp_3fc.s390 requires libgcj.so.6 p6spy - 1.3-2jpp_3fc.s390 requires libgcj.so.6 regexp - 1.3-2jpp_3fc.s390 requires libgcj.so.6 struts - 1.2.4-2jpp_3fc.s390 requires libgcj.so.6 struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.s390 requires libgcj.so.6 tetex-xdvi - 3.0-11.s390 requires libXm.so.3 tomcat5 - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 tomcat5-admin-webapps - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 tomcat5-jasper - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 tomcat5-webapps - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 xalan-j2 - 2.6.0-3jpp_4fc.s390 requires libgcj.so.6 xalan-j2-demo - 2.6.0-3jpp_4fc.s390 requires libgcj.so.6 xalan-j2-xsltc - 2.6.0-3jpp_4fc.s390 requires libgcj.so.6 xerces-j2 - 2.6.2-5jpp_2fc.s390 requires libgcj.so.6 xerces-j2-demo - 2.6.2-5jpp_2fc.s390 requires libgcj.so.6 xml-commons-apis - 1.0-0.b2.7jpp_3fc.s390 requires libgcj.so.6 xml-commons-which - 1.0-0.b2.7jpp_3fc.s390 requires libgcj.so.6 xpdf - 1:3.01-5.s390 requires libXm.so.3 Broken deps for s390x ---------------------------------------------------------- anaconda - 10.90.16-1.s390x requires anaconda-help carol - 1.8.9.3-1jpp_6fc.s390x requires libgcj.so.6()(64bit) gnu-crypto - 2.0.1-1jpp_8fc.s390x requires libgcj.so.6()(64bit) gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.s390x requires libgcj.so.6()(64bit) gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.s390x requires libgcj.so.6()(64bit) jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) jotm - 2.0.5-1jpp_3fc.s390x requires libgcj.so.6()(64bit) jsch - 0.1.18-1jpp_2fc.s390x requires libgcj.so.6()(64bit) libgconf-java - 2.12.0-2.s390x requires libgcj.so.6()(64bit) libgconf-java - 2.12.0-2.s390x requires libglibjava-0.2.so()(64bit) libgconf-java - 2.12.0-2.s390x requires libglibjni-0.2.so()(64bit) libgconf-java - 2.12.0-2.s390x requires libcairojava-1.0.so()(64bit) libglade-java - 2.12.0-5.s390x requires libgcj.so.6()(64bit) libglade-java - 2.12.0-5.s390x requires libglibjava-0.2.so()(64bit) libglade-java - 2.12.0-5.s390x requires libglibjni-0.2.so()(64bit) libglade-java - 2.12.0-5.s390x requires libcairojava-1.0.so()(64bit) libgnome-java - 2.12.0-2.s390x requires libgcj.so.6()(64bit) libgnome-java - 2.12.0-2.s390x requires libglibjava-0.2.so()(64bit) libgnome-java - 2.12.0-2.s390x requires libglibjni-0.2.so()(64bit) libgnome-java - 2.12.0-2.s390x requires libcairojava-1.0.so()(64bit) libgtk-java - 2.8.0-7.s390x requires libgcj.so.6()(64bit) libgtk-java - 2.8.0-7.s390x requires libglibjava-0.2.so()(64bit) libgtk-java - 2.8.0-7.s390x requires libglibjni-0.2.so()(64bit) libvte-java - 0.11.11-6.s390x requires libgcj.so.6()(64bit) libvte-java - 0.11.11-6.s390x requires libglibjava-0.2.so()(64bit) libvte-java - 0.11.11-6.s390x requires libglibjni-0.2.so()(64bit) libvte-java - 0.11.11-6.s390x requires libcairojava-1.0.so()(64bit) lucene - 1.4.3-1jpp_7fc.s390x requires libgcj.so.6()(64bit) lucene-demo - 1.4.3-1jpp_7fc.s390x requires libgcj.so.6()(64bit) monolog - 1.8.6-1jpp_5fc.s390x requires libgcj.so.6()(64bit) mx4j - 1:3.0.1-1jpp_5fc.s390x requires libgcj.so.6()(64bit) nanoxml - 2.2.3-3jpp_3fc.s390x requires libgcj.so.6()(64bit) nanoxml-lite - 2.2.3-3jpp_3fc.s390x requires libgcj.so.6()(64bit) oldkilim - 1.1.3-2jpp_3fc.s390x requires libgcj.so.6()(64bit) p6spy - 1.3-2jpp_3fc.s390x requires libgcj.so.6()(64bit) regexp - 1.3-2jpp_3fc.s390x requires libgcj.so.6()(64bit) struts - 1.2.4-2jpp_3fc.s390x requires libgcj.so.6()(64bit) struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.s390x requires libgcj.so.6()(64bit) tetex-xdvi - 3.0-11.s390x requires libXm.so.3()(64bit) tomcat5 - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) tomcat5-admin-webapps - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) tomcat5-jasper - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) tomcat5-webapps - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) xalan-j2 - 2.6.0-3jpp_4fc.s390x requires libgcj.so.6()(64bit) xalan-j2-demo - 2.6.0-3jpp_4fc.s390x requires libgcj.so.6()(64bit) xalan-j2-xsltc - 2.6.0-3jpp_4fc.s390x requires libgcj.so.6()(64bit) xerces-j2 - 2.6.2-5jpp_2fc.s390x requires libgcj.so.6()(64bit) xerces-j2-demo - 2.6.2-5jpp_2fc.s390x requires libgcj.so.6()(64bit) xml-commons-apis - 1.0-0.b2.7jpp_3fc.s390x requires libgcj.so.6()(64bit) xml-commons-which - 1.0-0.b2.7jpp_3fc.s390x requires libgcj.so.6()(64bit) xpdf - 1:3.01-5.s390x requires libXm.so.3()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 anaconda - 10.90.16-1.x86_64 requires anaconda-help carol - 1.8.9.3-1jpp_6fc.x86_64 requires libgcj.so.6()(64bit) cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 eclipse-bugzilla - 1:0.1.1_fc-5.x86_64 requires libgcj.so.6()(64bit) eclipse-cdt - 1:3.0.1-1jpp_1fc.x86_64 requires libgcj.so.6()(64bit) eclipse-changelog - 1:2.0.1_fc-22.x86_64 requires libgcj.so.6()(64bit) eclipse-ecj - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-jdt - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-pde - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-platform - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-pydev - 1:0.9.3_fc-12.x86_64 requires libgcj.so.6()(64bit) gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 gnu-crypto - 2.0.1-1jpp_8fc.x86_64 requires libgcj.so.6()(64bit) gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.x86_64 requires libgcj.so.6()(64bit) gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.x86_64 requires libgcj.so.6()(64bit) jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jotm - 2.0.5-1jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jsch - 0.1.18-1jpp_2fc.x86_64 requires libgcj.so.6()(64bit) libglade-java - 2.12.1-2.x86_64 requires libgcj.so.6()(64bit) libgnome-java - 2.12.1-2.x86_64 requires libgcj.so.6()(64bit) libgtk-java - 2.8.1-1.x86_64 requires libgcj.so.6()(64bit) libswt3-gtk2 - 1:3.1.1-1jpp_9fc.x86_64 requires libgcjawt.so.6()(64bit) libswt3-gtk2 - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) libvte-java - 0.11.11-6.x86_64 requires libgcj.so.6()(64bit) lucene - 1.4.3-1jpp_7fc.x86_64 requires libgcj.so.6()(64bit) lucene-demo - 1.4.3-1jpp_7fc.x86_64 requires libgcj.so.6()(64bit) monolog - 1.8.6-1jpp_5fc.x86_64 requires libgcj.so.6()(64bit) mx4j - 1:3.0.1-1jpp_5fc.x86_64 requires libgcj.so.6()(64bit) nanoxml - 2.2.3-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) nanoxml-lite - 2.2.3-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) oldkilim - 1.1.3-2jpp_3fc.x86_64 requires libgcj.so.6()(64bit) openoffice.org-core - 1:2.0.1-143.1.2.i386 requires libgcjawt.so.6 openoffice.org-core - 1:2.0.1-143.1.2.i386 requires libgcj.so.6 p6spy - 1.3-2jpp_3fc.x86_64 requires libgcj.so.6()(64bit) regexp - 1.3-2jpp_3fc.x86_64 requires libgcj.so.6()(64bit) struts - 1.2.4-2jpp_3fc.x86_64 requires libgcj.so.6()(64bit) struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.x86_64 requires libgcj.so.6()(64bit) systemtap - 0.5-2.x86_64 requires libdw.so.1(ELFUTILS_0.116)(64bit) tetex-xdvi - 3.0-11.x86_64 requires libXm.so.3()(64bit) tomcat5 - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) tomcat5-admin-webapps - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) tomcat5-jasper - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) tomcat5-webapps - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) xalan-j2 - 2.6.0-3jpp_4fc.x86_64 requires libgcj.so.6()(64bit) xalan-j2-demo - 2.6.0-3jpp_4fc.x86_64 requires libgcj.so.6()(64bit) xalan-j2-xsltc - 2.6.0-3jpp_4fc.x86_64 requires libgcj.so.6()(64bit) xerces-j2 - 2.6.2-5jpp_2fc.x86_64 requires libgcj.so.6()(64bit) xerces-j2-demo - 2.6.2-5jpp_2fc.x86_64 requires libgcj.so.6()(64bit) xml-commons-apis - 1.0-0.b2.7jpp_3fc.x86_64 requires libgcj.so.6()(64bit) xml-commons-which - 1.0-0.b2.7jpp_3fc.x86_64 requires libgcj.so.6()(64bit) xpdf - 1:3.01-5.x86_64 requires libXm.so.3()(64bit) From alan at redhat.com Sun Dec 11 17:13:29 2005 From: alan at redhat.com (Alan Cox) Date: Sun, 11 Dec 2005 12:13:29 -0500 Subject: yum clean bug In-Reply-To: <1134156134.3010.117.camel@yoda.loki.me> References: <22905.192.54.193.25.1134142460.squirrel@rousalka.dyndns.org> <1134142976.3010.39.camel@yoda.loki.me> <4399BE90.7080809@laposte.net> <1134150137.3010.75.camel@yoda.loki.me> <4399C652.9090902@laposte.net> <1134151788.3010.84.camel@yoda.loki.me> <4399CF6E.6010906@laposte.net> <604aa7910512091100r5df30972w2092a9385a30fdc4@mail.gmail.com> <4399D79C.208@laposte.net> <1134156134.3010.117.camel@yoda.loki.me> Message-ID: <20051211171329.GD12031@devserv.devel.redhat.com> On Fri, Dec 09, 2005 at 11:22:14AM -0800, Jesse Keating wrote: > remain. Cache does you no good if you just remove it every single time > it gets written. Theoretically you can do this, because of hte way that > cache works, and how the FHS says that cache should work. However a lot > of times this isn't a desirable usage. The point of /var/cache is to _keep_ stuff around unless it turns out the space is needed for something else. That means apps can expect bits of /var/cache just to vanish and must be robust if they do. It does not mean they are obliged in any way to clear their own cache regularly or per run. That behaviour is /tmp behaviour instead. From jdieter99 at gmx.net Sun Dec 11 19:30:01 2005 From: jdieter99 at gmx.net (Jonathan Dieter) Date: Sun, 11 Dec 2005 21:30:01 +0200 Subject: RPM Patching In-Reply-To: <20051211181329.GA1115@suse.de> References: <439AEB31.6030502@gmx.net> <1cef3e950512100656h2dd3e674s2043c9b3c21bfabe@mail.gmail.com> <439B5D64.7070409@gmx.net> <20051211181329.GA1115@suse.de> Message-ID: <439C7E39.6050703@gmx.net> Sorry, I was looking at an older version of your software. My mistake. Well, it seems the last thing to do is setting up yum to be able to use deltarpms. Or has that already been done? Michael Schroeder wrote: >On Sun, Dec 11, 2005 at 12:57:40AM +0200, Jonathan Dieter wrote: > > >>There's really not much of anything I can add except the fact that I'm >>dealing with the RPMs on a file by file basis, which means you don't >>necessarily have to have the original RPM when applying the patch. You >>just have to have installed it on your system. >> >> > >Yes, my deltarpm package also supports this. (It was actually >one of the design goals.) > >I'm also using bsdiff, but changed the algorithm to use a hash instead >of a suffix tree, because the suffix tree takes way too much time for >large archives. > >Cheers, > Michael. > > > From fedora-devel-list at cygnusx-1.org Sun Dec 11 20:02:24 2005 From: fedora-devel-list at cygnusx-1.org (Nathan Grennan) Date: Sun, 11 Dec 2005 12:02:24 -0800 Subject: sky2 and hard drive performance Message-ID: <439C85D0.4060804@cygnusx-1.org> Yesterday I converted my FC4 system from raid0 to raid5. After creating the raid5 arrays I tested the speed with hdparm while in rescue mode. I saw awesome speeds. hdparm -tT /dev/md2 /dev/md2: Timing cached reads: 4532 MB in 2.00 seconds = 2265.86 MB/sec Timing buffered disk reads: 494 MB in 3.00 seconds = 164.66 MB/sec Then after I finished copying all the data over, setup grub, and got the system back to normal I repeatedly the test in a terminal window. hdparm -tT /dev/md2 /dev/md2: Timing cached reads: 1320 MB in 2.00 seconds = 658.64 MB/sec Timing buffered disk reads: 256 MB in 3.01 seconds = 85.10 MB/sec I then went back in to rescue mode and found that the speed was the same as it had been before. Then I booted into single user mode and saw the same. Next I started up services in the order they would normally start. After each service I would repeat the test. I started kudzu and iptables. After each the results were roughly the same. Then I started network and the performance dropped. My first guess was then the sky2 driver. So I activated the other interfaces, but not the sky2 interface. The hdparm results were normal. Then I activated the sky2 interface and it dropped again. I do see that the driver can be loaded without a drop in performance, it is only activating the driver that triggers it. Another thing I see is that deactivating it doesn't fix the problem. In that I can go from run level 5 to run level 1, where networking is shut down in the process, but the performance in run level 1 will still be slow. Another potential clue maybe that I didn't see such a drop with raid0 performance when I started using the sky2 driver. So I suspect it is just an interaction between the raid5 code and the sky2 code. Who's bugzilla should bug reports for this driver go into? I also wanted to bring up again the crash on reactivation, especially since I haven't mentioned it to Stephen before. Unable to handle kernel NULL pointer dereference at 00000000000000e8 RIP: {:sky2:sky2_tx_complete+230} PGD 7d481067 PUD 796a7067 PMD 0 Oops: 0000 [1] CPU 0 Modules linked in: ipv6 dm_mirror dm_mod raid1 raid0 video button battery ac ohci1394 ieee1394 ohci_hcd ehci_hcd parport_pc parport i2c_nforce2 i2c_core shpchp snd_intel8x0 snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_emul snd_emu10k1 snd_rawmidi snd_ac97_codec snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss snd_mixer_oss snd_pcm snd_timer snd_ac97_bus snd_page_alloc snd_util_mem snd_hwdep snd soundcore sky2 8139too mii forcedeth floppy ext3 jbd sata_sil sata_nv libata sd_mod scsi_mod Pid: 3014, comm: ip Not tainted 2.6.14-1.1644_FC4.netdev.4 #1 RIP: 0010:[] {:sky2:sky2_tx_complete+230} RSP: 0018:ffffffff80493058 EFLAGS: 00010292 RAX: 0000000000020000 RBX: ffff81007e9a7800 RCX: 0000000000000001 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff81007fd41870 RBP: 0000000000000000 R08: 0000000000000000 R09: 0000000000000000 R10: 0000000000000000 R11: 0000000000000001 R12: ffff81007e9a7c00 R13: ffff8100797d0000 R14: 0000000000000008 R15: 0000000000000008 FS: 00002aaaaaabf990(0000) GS:ffffffff804f9000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b CR2: 00000000000000e8 CR3: 0000000079658000 CR4: 00000000000006e0 Process ip (pid: 3014, threadinfo ffff810079036000, task ffff8100797f3800) Stack: ffffffff80154b00 ffff81007e9a7c28 ffff81007e9a7800 ffff81007e9a7800 ffff8100032384c0 0000000000000000 00000000ffff21c7 00007fffffa16f10 ffffffff80493188 ffffffff880ac20e Call Trace: {__do_IRQ+213} {:sky2:sky2_poll+1949} {ret_from_intr+0} {net_rx_action+154} {__do_softirq+74} {call_softirq+31} {do_softirq+44} {do_IRQ+52} {ret_from_intr+0} {dma_alloc_pages+71} {dma_alloc_pages+38} {dma_alloc_coherent+125} {:sky2:sky2_up+193} {dev_open+55} {dev_change_flags+99} {devinet_ioctl+671} {dev_ioctl+818} {sock_ioctl+656} {do_ioctl+27} {vfs_ioctl From tmus at tmus.dk Sun Dec 11 20:13:13 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Sun, 11 Dec 2005 21:13:13 +0100 Subject: yum clean bug In-Reply-To: <1134301616.12691.24.camel@laurel.intra.city-fan.org> References: <604aa7910512081243x773b3cf4ree658a884e151752@mail.gmail.com> <1134081037.23944.58.camel@cutter> <1134082136.23944.69.camel@cutter> <4398BA2B.2040607@n-man.com> <1134301616.12691.24.camel@laurel.intra.city-fan.org> Message-ID: Paul Howarth wrote: > > It'll break setups where multiple machines are sharing a cache and not > using exactly the same set of repos. > Well? I guess i could live with that. When you think about it, running yum clean on a setup like this, will cause some stuff to be rebuilt anyway, right? /Thomas From wtogami at redhat.com Sun Dec 11 20:20:21 2005 From: wtogami at redhat.com (Warren Togami) Date: Sun, 11 Dec 2005 15:20:21 -0500 Subject: sky2 and hard drive performance In-Reply-To: <439C85D0.4060804@cygnusx-1.org> References: <439C85D0.4060804@cygnusx-1.org> Message-ID: <439C8A05.8040606@redhat.com> Nathan Grennan wrote: > > I do see that the driver can be loaded without a drop in performance, > it is only activating the driver that triggers it. Another thing I see > is that deactivating it doesn't fix the problem. In that I can go from > run level 5 to run level 1, where networking is shut down in the > process, but the performance in run level 1 will still be slow. > > Another potential clue maybe that I didn't see such a drop with raid0 > performance when I started using the sky2 driver. So I suspect it is > just an interaction between the raid5 code and the sky2 code. > > Who's bugzilla should bug reports for this driver go into? > You should test it with the latest vanilla upstream kernel sources like 2.6.14.X and 2.6.15-rcX-gitY. If they are still broken there, then file a bug at bugzilla.kernel.org. Warren Togami wtogami at redhat.com From naheemzaffar at gmail.com Sun Dec 11 20:21:55 2005 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Sun, 11 Dec 2005 20:21:55 +0000 Subject: gstreamer 0.10 In-Reply-To: <1134143154.11873.55.camel@localhost.localdomain> References: <1134100748.11873.9.camel@localhost.localdomain> <43999BEE.6030002@conversis.de> <1134143154.11873.55.camel@localhost.localdomain> Message-ID: <3adc77210512111221u409de288l622211bdc089adf0@mail.gmail.com> Fedora has a mission statement to include the latest and greatest stable software. Gstreamer 0.10 is such software. If there is a big compatibility issue, maybe also release gstreamer 0.8 as a gstreamer-compat (maybe in extras)? both are parallel installable. This would force people to migrate faster to an updated platform, and gstreamer is supposed to have many updates that fix many problems. Even plugins are divided into three parts. Good: well written plugins without legal/lincensing issues. Bad: well written plugins with either patent/licence problems. Ugly: ugly code. once cleaned up wil go into good or bad depending on relevant issues. I did not think there would be a day fedora would shy away from the latest stuff. If there are problesm, well that is the point of rawhide and test releases. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora-devel-list at cygnusx-1.org Sun Dec 11 22:19:29 2005 From: fedora-devel-list at cygnusx-1.org (Nathan Grennan) Date: Sun, 11 Dec 2005 14:19:29 -0800 Subject: sky2 and hard drive performance In-Reply-To: <439C8A05.8040606@redhat.com> References: <439C85D0.4060804@cygnusx-1.org> <439C8A05.8040606@redhat.com> Message-ID: <439CA5F1.4060108@cygnusx-1.org> Warren Togami wrote: > You should test it with the latest vanilla upstream kernel sources > like 2.6.14.X and 2.6.15-rcX-gitY. If they are still broken there, > then file a bug at bugzilla.kernel.org. It isn't that simple. The sky2 driver is not in 2.6.14.3 or 2.6.15-rc5-git1. It is from the netdev tree. Which means bugzilla.kernel.org is probably not the right place. From reuben-fedora-devel at reub.net Sun Dec 11 22:28:32 2005 From: reuben-fedora-devel at reub.net (Reuben Farrelly) Date: Mon, 12 Dec 2005 11:28:32 +1300 Subject: sky2 and hard drive performance In-Reply-To: <439CA5F1.4060108@cygnusx-1.org> References: <439C85D0.4060804@cygnusx-1.org> <439C8A05.8040606@redhat.com> <439CA5F1.4060108@cygnusx-1.org> Message-ID: <439CA810.5090608@reub.net> On 12/12/2005 11:19 a.m., Nathan Grennan wrote: > Warren Togami wrote: >> You should test it with the latest vanilla upstream kernel sources >> like 2.6.14.X and 2.6.15-rcX-gitY. If they are still broken there, >> then file a bug at bugzilla.kernel.org. > It isn't that simple. The sky2 driver is not in 2.6.14.3 or > 2.6.15-rc5-git1. It is from the netdev tree. Which means > bugzilla.kernel.org is probably not the right place. Why don't you email the sky2 driver author Stephen Hemminger directly about it at rather than here, as I suggested to you last time you were having problems with the driver? That way it will get fixed upstream by the guy who actually knows the card and driver code inside out, and everyone will benefit. Reuben From fedora-devel-list at cygnusx-1.org Sun Dec 11 22:37:18 2005 From: fedora-devel-list at cygnusx-1.org (Nathan Grennan) Date: Sun, 11 Dec 2005 14:37:18 -0800 Subject: sky2 and hard drive performance In-Reply-To: <439CA810.5090608@reub.net> References: <439C85D0.4060804@cygnusx-1.org> <439C8A05.8040606@redhat.com> <439CA5F1.4060108@cygnusx-1.org> <439CA810.5090608@reub.net> Message-ID: <439CAA1E.6080901@cygnusx-1.org> Reuben Farrelly wrote: > Why don't you email the sky2 driver author Stephen Hemminger directly > about it at rather than here, as I suggested to > you last time you were having problems with the driver? > > That way it will get fixed upstream by the guy who actually knows the > card and driver code inside out, and everyone will benefit. I don't remember you suggesting that, but if you notice, I did send a copy to him on the original message in this thread. I also send a copy to John Linville who maintains the netdev kernel yum repository. I thought others would be interested in this problem, since I am not the only one using the netdev kernels, and probably not the only one using the sky2 driver. From reuben-fedora-devel at reub.net Sun Dec 11 22:46:36 2005 From: reuben-fedora-devel at reub.net (Reuben Farrelly) Date: Mon, 12 Dec 2005 11:46:36 +1300 Subject: sky2 and hard drive performance In-Reply-To: <439CAA1E.6080901@cygnusx-1.org> References: <439C85D0.4060804@cygnusx-1.org> <439C8A05.8040606@redhat.com> <439CA5F1.4060108@cygnusx-1.org> <439CA810.5090608@reub.net> <439CAA1E.6080901@cygnusx-1.org> Message-ID: <439CAC4C.3070809@reub.net> On 12/12/2005 11:37 a.m., Nathan Grennan wrote: > Reuben Farrelly wrote: >> Why don't you email the sky2 driver author Stephen Hemminger directly >> about it at rather than here, as I suggested to >> you last time you were having problems with the driver? >> >> That way it will get fixed upstream by the guy who actually knows the >> card and driver code inside out, and everyone will benefit. > I don't remember you suggesting that, but if you notice, I did send a Message-ID: <4391A7F7.50900 at reub.net> Date: Sun, 04 Dec 2005 03:13:11 +1300 > copy to him on the original message in this thread. I also send a copy Indeed, I didn't notice. I apologise ;-) Reuben From dwmw2 at infradead.org Sun Dec 11 23:34:31 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Mon, 12 Dec 2005 00:34:31 +0100 Subject: sky2 and hard drive performance In-Reply-To: <439C85D0.4060804@cygnusx-1.org> References: <439C85D0.4060804@cygnusx-1.org> Message-ID: <1134344072.10234.36.camel@localhost.localdomain> On Sun, 2005-12-11 at 12:02 -0800, Nathan Grennan wrote: > I do see that the driver can be loaded without a drop in performance, > it is only activating the driver that triggers it. Another thing I see > is that deactivating it doesn't fix the problem. In that I can go from > run level 5 to run level 1, where networking is shut down in the > process, but the performance in run level 1 will still be slow. > > Another potential clue maybe that I didn't see such a drop with raid0 > performance when I started using the sky2 driver. So I suspect it is > just an interaction between the raid5 code and the sky2 code. Just before leaving home last week I noticed that sky2 was causing an interrupt storm on my new toy, which explained the massive performance problems I saw there. Since I'd just taken the sky2.[ch] from the netdev git tree and compiled them against the Fedora kernel I didn't report it; just intended to look into it further when I got home. -- dwmw2 From d.jacobfeuerborn at conversis.de Sun Dec 11 23:52:32 2005 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Mon, 12 Dec 2005 00:52:32 +0100 Subject: gstreamer 0.10 In-Reply-To: <3adc77210512111221u409de288l622211bdc089adf0@mail.gmail.com> References: <1134100748.11873.9.camel@localhost.localdomain> <43999BEE.6030002@conversis.de> <1134143154.11873.55.camel@localhost.localdomain> <3adc77210512111221u409de288l622211bdc089adf0@mail.gmail.com> Message-ID: <439CBBC0.2070201@conversis.de> Naheem Zaffar wrote: > I did not think there would be a day fedora would shy away from the > latest stuff. If there are problesm, well that is the point of rawhide > and test releases. Right now the problem is that software that actually makes use of gstreamer 0.10 seems to be hard to come by. After giving up on Banshee I tried Rhythmbox HEAD which kinda works but not really. Playing a file doesn't work right away and I have to give the seekbar a little nudge to make it start playing. Unfortunately that's actually more than I get out of Rhythmbox with gstreamer 0.8 (see https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174917 ). Yes, it would be cool to get that in but right now there would be very little gain for users running things "out of the box". Regards, Dennis From fedora-devel-list at cygnusx-1.org Sun Dec 11 23:58:09 2005 From: fedora-devel-list at cygnusx-1.org (Nathan Grennan) Date: Sun, 11 Dec 2005 15:58:09 -0800 Subject: sky2 and hard drive performance In-Reply-To: <1134344072.10234.36.camel@localhost.localdomain> References: <439C85D0.4060804@cygnusx-1.org> <1134344072.10234.36.camel@localhost.localdomain> Message-ID: <439CBD11.8030202@cygnusx-1.org> David Woodhouse wrote: > Just before leaving home last week I noticed that sky2 was causing an > interrupt storm on my new toy, which explained the massive performance > problems I saw there. Since I'd just taken the sky2.[ch] from the netdev > git tree and compiled them against the Fedora kernel I didn't report it; > just intended to look into it further when I got home I just downloaded the latest sk98lin driver from the Syskonnect site. I compiled it against kernel-2.6.14-1.1644_FC4.x86_64, and loaded it. It seems to work, it doesn't crash the system on reactivation, and doesn't degrade my hard drive performance. I had avoided sk98lin from the Syskonnect site, because of messages I had found that said it was poorly written and that sky2 was supposed to be well written. Maybe it isn't written to the linux kernel standards, but it at least works better than the latest version of sky2. I think I will keep my eye on sky2, but use sk98lin for now. From linville at redhat.com Mon Dec 12 03:04:18 2005 From: linville at redhat.com (John W. Linville) Date: Sun, 11 Dec 2005 22:04:18 -0500 Subject: sky2 and hard drive performance In-Reply-To: <439CE62F.9050609@osdl.org> References: <439C85D0.4060804@cygnusx-1.org> <1134344072.10234.36.camel@localhost.localdomain> <439CE62F.9050609@osdl.org> Message-ID: <20051212030418.GA22877@redhat.com> On Sun, Dec 11, 2005 at 06:53:35PM -0800, Stephen Hemminger wrote: > David Woodhouse wrote: > > >On Sun, 2005-12-11 at 12:02 -0800, Nathan Grennan wrote: > > > > > >> I do see that the driver can be loaded without a drop in performance, > >>it is only activating the driver that triggers it. Another thing I see > >>is that deactivating it doesn't fix the problem. In that I can go from > >>run level 5 to run level 1, where networking is shut down in the > >>process, but the performance in run level 1 will still be slow. > >> > >> Another potential clue maybe that I didn't see such a drop with raid0 > >>performance when I started using the sky2 driver. So I suspect it is > >>just an interaction between the raid5 code and the sky2 code. > >> > >> > > > >Just before leaving home last week I noticed that sky2 was causing an > >interrupt storm on my new toy, which explained the massive performance > >problems I saw there. Since I'd just taken the sky2.[ch] from the netdev > >git tree and compiled them against the Fedora kernel I didn't report it; > >just intended to look into it further when I got home. > > > > > > > Doesn't anybody read the mailing lists... There was a missing interrupt > clear that was fixed about 1 day later. That patch didn't make it into FC4.netdev.4. I'm spinning FC4.netdev.5 now, w/ just that patch added. John -- John W. Linville linville at redhat.com From jiangguowei2000 at hotmail.com Mon Dec 12 05:47:54 2005 From: jiangguowei2000 at hotmail.com (jiang guowei) Date: Mon, 12 Dec 2005 05:47:54 +0000 Subject: Why not do an all-sided testing for fedora? Message-ID: Hi! Ostl(Open Source Testing Lab) has ever done an all-sided testing for ubuntu5.04, and published their testing report at http://www.paul.sladen.org/ubuntu/ostl/UbuntuDefectReport.pdf http://www.paul.sladen.org/ubuntu/ostl/UbuntuTestingReport.pdf or http://snipurl.com/UbuntuDefectReport http://snipurl.com/UbuntuTestingReport Why not ask ostl to do a similar testing for our fedora?All is free. _________________________________________________________________ ???? MSN Explorer: http://explorer.msn.com/lccn From johnp at redhat.com Mon Dec 12 06:08:21 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Mon, 12 Dec 2005 01:08:21 -0500 Subject: gstreamer 0.10 In-Reply-To: <3adc77210512111221u409de288l622211bdc089adf0@mail.gmail.com> References: <1134100748.11873.9.camel@localhost.localdomain> <43999BEE.6030002@conversis.de> <1134143154.11873.55.camel@localhost.localdomain> <3adc77210512111221u409de288l622211bdc089adf0@mail.gmail.com> Message-ID: <1134367701.26358.11.camel@localhost.localdomain> On Sun, 2005-12-11 at 20:21 +0000, Naheem Zaffar wrote: > Fedora has a mission statement to include the latest and greatest > stable software. Gstreamer 0.10 is such software. Then by all mean package it up for Extras. There is always a plan, we don't just blindly add packages. At minimum for core there needs to be an application that pulls it in as of yet all packages that use 0.10 are not stable. I have been investigating it and right now apps just work better with 0.8. That is not to say I don't want to get it in, it will eventually land in core and packaging it up now might accelerate the porting of apps but, right now I don't know when I will have time to get to it. If someone packages it up for extras it makes it that much easier for me to pull it into core, otherwise be patient. > If there is a big compatibility issue, maybe also release gstreamer > 0.8 as a gstreamer-compat (maybe in extras)? both are parallel > installable. I would rather have just one library, we are trying to manage the size of core but if fc5 rolls around and we need both we will ship both. > This would force people to migrate faster to an updated platform, and > gstreamer is supposed to have many updates that fix many problems. > Even plugins are divided into three parts. Good: well written plugins > without legal/lincensing issues. Bad: well written plugins with either > patent/licence problems. Ugly: ugly code. once cleaned up wil go into > good or bad depending on relevant issues. Yes this is great but it also means we need to spend some time on packaging it and having it play nice with the old gstreamer packages. As I said it would be great to get this into extras since it will leave me time to figure out how we are going to integrate it into core. > I did not think there would be a day fedora would shy away from the > latest stuff. If there are problesm, well that is the point of rawhide > and test releases. Cart before the horse though. We don't just throw thing in. The modular X releases went through a lot before they made it into rawhide. -- John (J5) Palmieri From buildsys at redhat.com Mon Dec 12 11:22:43 2005 From: buildsys at redhat.com (Build System) Date: Mon, 12 Dec 2005 06:22:43 -0500 Subject: rawhide report: 20051212 changes Message-ID: <200512121122.jBCBMh3T002898@porkchop.devel.redhat.com> Updated Packages: Pyrex-0:0.9.3.1-2.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt evolution-2.5.2-1.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt * Wed Dec 07 2005 David Malcolm - 2.5.2-1 - 2.5.2 - bump gtkhtml requirement from 3.7.6 to 3.9.2 - bump eds requirement from 1.4.1.1 to 1.5.2 - bump evo_major from 2.4 to 2.6 - updated patch 107 - updated patch 108 - updated patch 800, replacing rh-161817-attach-116019-conduit_pilot_link_updates.diff with evolution-2.5.2-fix-conduits.patch. Not yet complete. - disable pilot support for now (see #175160) - added hula plugin to list of packaged plugins - generalize gconf schema packaging to support changing evo_major * Fri Dec 02 2005 David Malcolm - 2.4.2-2 - force regeneration of the intltool files to prevent a problem where the tarball copy of intltool-merge.in was out of sync with the intltool.m4 in the latest shipped copy of intltool, which resulted in a broken intltool-merge script when the tree was reautotooled. (appears that the tarball was built with a CVS copy of intltool where @EXPANDED_LIBDIR@ had been renamed to @INTLTOOL_LIBDIR@, but our aclocal/intltool.m4 doesn't yet reflect that change) evolution-data-server-1.5.2-1.1 ------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt expect-5.43.0-2.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt fetchmail-6.3.0-1.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt file-4.16-4.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt * Tue Nov 29 2005 Radek Vokal - 4.16-4 - printf utf8 filenames and don't use isprint() (#174348) * Tue Nov 08 2005 Radek Vokal - 4.16-3 - remove .la files (#172633) filesystem-2.3.7-1.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt findutils-1:4.2.27-1.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt finger-0.17-30.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt firefox-1.5-1.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt flac-1.1.2-25.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt foomatic-3.0.2-29.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt freeglut-2.4.0-2.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt freeradius-1.0.4-5.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt g-wrap-1.3.4-9.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gail-1.8.8-1.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gaim-1:1.5.0-9.fc5.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gal-1:0.24-6.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gamin-0.1.7-1.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gawk-3.1.5-4.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gconf-editor-2.12.1-1.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gd-2.0.33-5.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt * Wed Nov 02 2005 Phil Knirsch 2.0.33-5 - Switched BuildPreReqs and Requires to modular xorg-x11 style * Mon Oct 10 2005 Phil Knirsch 2.0.33-4 - Fixed possible gd crash when drawing AA line near image borders (#167843) gdbm-1.8.0-25.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gdk-pixbuf-1:0.22.0-21.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt gdm-1:2.8.0.4-13.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt gedit-1:2.12.1-1.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt genromfs-0.5.1-3.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt gftp-1:2.0.18-3.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt ghostscript-8.15.1-3.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt giflib-4.1.3-6.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gimp-2:2.2.9-3.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt * Fri Dec 09 2005 Nils Philippsen - build with -fomit-frame-pointer to let assembly build with gcc 4.1 * Fri Dec 02 2005 Nils Philippsen - build with gcc 4.1 gimp-print-4.2.7-13.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gkrellm-2.2.7-5.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt glade2-2.12.1-1.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gmp-4.1.4-6.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-bluetooth-0.6.0-2.1 ------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-desktop-2.13.2-1.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-games-1:2.13.2-1.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-kerberos-0.3.3-2.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-keyring-0.4.6-1.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-keyring-manager-2.12.0-2.1 -------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-libs-1:1.4.1.2.90-46.1 ---------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-mag-0.12.2-2.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-media-2.12.0-3.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-menus-2.12.0-1.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-mime-data-2.4.2-1.1 ------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-netstatus-2.12.0-3.1 -------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-nettool-1.2.0-1.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-panel-2.13.2-1.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-pilot-2.0.13-7.fc5.1 -------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-pilot-conduits-2.0.13-2.FC5.1 ----------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-print-1:0.37-12.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-spell-1.0.5-10.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-system-monitor-2.13.2-1.1 ------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-terminal-2.12.0-2.1 ------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-themes-2.13.2-1.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-user-docs-2.8.1-2.1 ------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-user-share-0.9-1.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt gnopernicus-0.12.0-2.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gnu.getopt-0:1.0.9-4jpp_2fc.1.1 ------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gnu.regexp-0:1.1.4-7jpp_1fc.1 ----------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gnupg-1.4.2-3.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gnuplot-4.0.0-10.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt gob2-2.0.12-1.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gok-1.0.5-6.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gpart-0.1h-1.1 -------------- gperf-3.0.1-7.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt grep-2.5.1-51.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gsl-1.7-1.1 ----------- * Fri Dec 09 2005 Jesse Keating - rebuilt gtk+-1:1.2.10-49.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt gtk-doc-1.4-1.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gtk-engines-1:0.12-7.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gtkhtml2-2.6.3-1.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt gtkhtml3-3.9.2-1.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt gtksourceview-1.5.1-2.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gtkspell-2.0.11-1.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt guile-5:1.6.7-4.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gulm-1.0.4-2.FC5.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt gwenhywfar-1.7.2-3.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gzip-1.3.5-6.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt h2ps-2.06-14.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt hardlink-1:1.0-1.19.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt hdparm-6.3-1.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt * Wed Nov 30 2005 Karsten Hopp 6.3-1 - fix package URL hesiod-3.0.2-31.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt hexedit-1.2.12-2.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt hfsutils-3.2.6-7.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt hicolor-icon-theme-0.8-3.1 -------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt hotplug-3:2004_09_23-10.1 ------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt hplip-0.9.7-3.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt htmlview-3.0.0-13.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt httpd-2.2.0-3.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt hwbrowser-0.24-1.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt hwdata-0.172-1.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt icon-slicer-0.3-7.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt iddev-2.0.0-4.FC5.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt imake-0.99.2-5.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt imlib-1:1.9.13-26.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt indent-2.2.9-8.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt initscripts-8.18-1.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt inn-2.4.2-4.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt intltool-0.34.1-1.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt iproute-2.6.14-11 ----------------- * Mon Dec 12 2005 Radek Vokal 2.6.14-11 - rebuilt ipsec-tools-0.6.3-1.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt iptables-1.3.4-2.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt iptraf-2.7.0-15.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt iptstate-1.4-1.1.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt iputils-20020927-31.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt ipv6calc-0.50-1.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt ipvsadm-1.24-7.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt irda-utils-0.9.16-7.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt isicom-3.05-18.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt iso-codes-0.47-1.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt jadetex-3.12-13.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt jdepend-0:2.6-2jpp_4fc.1.1 -------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt jdom-0:1.0-1jpp_2fc.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt jgroups-0:2.2.6-1jpp_1fc.1 -------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt jlex-0:1.2.6-1jpp_2fc.1.1 ------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt joe-3.3-1.1 ----------- * Fri Dec 09 2005 Jesse Keating - rebuilt jorm-0:2.4.3-1jpp_2fc.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt jorm-rdb-adapter-0:2.6-1jpp_1fc.1 --------------------------------- joystick-1.2.15-20.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt jpilot-0.99.8-2.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt jrefactory-0:2.8.9-3jpp_1fc.1.1 ------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt junit-0:3.8.1-3jpp_5fc.1.1 -------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt jwhois-3.2.3-3.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt jzlib-0:1.0.5-2jpp_1fc.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt k3b-0:0.12.8-1.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt kbd-1.12-12.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt kcc-2.3-24.1 ------------ * Fri Dec 09 2005 Jesse Keating - rebuilt kdbg-1:2.0.0-2.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt kde-i18n-1:3.5.0-1.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt kdeaccessibility-1:3.5.0-1.1 ---------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt kdeaddons-3.5.0-1.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt kdeadmin-7:3.5.0-1.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt kdeartwork-3.5.0-1.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt kdebindings-3.5.0-1.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt kdeedu-3.5.0-1.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt kdegames-6:3.5.0-1.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt kdegraphics-7:3.5.0-1.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt kdemultimedia-6:3.5.0-1.1 ------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt kdenetwork-7:3.5.0-1.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt kdepim-6:3.5.0-0.1.rc2.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt kdesdk-3.5.0-1.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt kdeutils-6:3.5.0-1.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt kdewebdev-6:3.5.0-1.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt kernel-2.6.14-1.1752_FC5 ------------------------ * Sun Dec 11 2005 Dave Jones - Re-add ISA soundblaster drivers. (#175492) * Sat Dec 10 2005 Dave Jones - Disable guessing of how many x86-64 hotplug cpus to add. * Sat Dec 10 2005 David Woodhouse - Work around GCC PR25248 - Fix parport_pc driver to check before poking at legacy I/O ports kon2-0.3.9b-26.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt krb5-1.4.3-1.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt * Thu Dec 01 2005 Nalin Dahyabhai - login: don't truncate passwords before passing them into crypt(), in case they're significant (#149476) krbafs-1.2.2-9.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt kudzu-1.2.14-1.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt lam-2:7.1.1-8.FC5.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt latex2html-2002.2.1-5.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt ldapjdk-0:4.17-1jpp_3fc.1.1 --------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt less-394-1.1 ------------ * Fri Dec 09 2005 Jesse Keating - rebuilt libcap-1.10-23.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libselinux-1.29.1-2 ------------------- * Sun Dec 11 2005 Dan Walsh 1.29.1-2 - update to latest libsetrans * Fri Dec 09 2005 Jesse Keating - rebuilt man-pages-ru-0.97-1.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt objectweb-anttask-0:1.2-1jpp_1fc.1.1 ------------------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt oro-0:2.0.8-1jpp_3fc.1.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt passivetex-1.25-5.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt perseus-cache-0:1.3.4-1jpp_1fc.1 -------------------------------- perseus-concurrency-0:1.4-1jpp_1fc.1 ------------------------------------ perseus-dependency-0:1.4-1jpp_1fc.1 ----------------------------------- perseus-distribution-0:1.3.2-1jpp_1fc.1 --------------------------------------- perseus-fos-0:1.3.1-1jpp_1fc.1 ------------------------------ perseus-persistence-0:1.3.4-1jpp_1fc.1 -------------------------------------- perseus-pool-0:1.3.3-1jpp_1fc.1 ------------------------------- php-pear-1:1.4.5-4.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt ppc64-utils-0.9-12.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt psgml-1.2.5-4.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt puretls-0.9-0.b4.1jpp_2fc.1.1 ----------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt pychecker-0.8.16-1.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt pydict-0.3.0-8.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt python-pyblock-0.7-1 -------------------- * Sun Dec 11 2005 Peter Jones - 0.7-1 - merge debugging work from last several weeks * Fri Dec 09 2005 Jesse Keating - 0.6-3.1 - rebuilt rootfiles-8.1-1.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt rpm-4.4.2-11 ------------ * Thu Dec 01 2005 Paul Nasrat - 4.4.2-11 - Remove rpm .la files (#174261) - Cron job use paths (#174211) selinux-policy-2.1.2-2 ---------------------- * Sat Dec 10 2005 Dan Walsh 2.1.2-2 - Allow unconfined_t to execmod texrel_shlib_t system-config-language-1.1.10-1.1 --------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt yaboot-1.3.13-0.16.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 anaconda - 10.90.16-1.i386 requires anaconda-help carol - 1.8.9.3-1jpp_6fc.i386 requires libgcj.so.6 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel = 0:2.6.14-1.1696_FC5 cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5smp cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 eclipse-bugzilla - 1:0.1.1_fc-5.i386 requires libgcj.so.6 eclipse-cdt - 1:3.0.1-1jpp_1fc.i386 requires libgcj.so.6 eclipse-changelog - 1:2.0.1_fc-22.i386 requires libgcj.so.6 eclipse-ecj - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-jdt - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-pde - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-platform - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-pydev - 1:0.9.3_fc-12.i386 requires libgcj.so.6 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel = 0:2.6.14-1.1696_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 gnu-crypto - 2.0.1-1jpp_8fc.i386 requires libgcj.so.6 gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.i386 requires libgcj.so.6 gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.i386 requires libgcj.so.6 jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jotm - 2.0.5-1jpp_3fc.i386 requires libgcj.so.6 jsch - 0.1.18-1jpp_2fc.i386 requires libgcj.so.6 libglade-java - 2.12.1-2.i386 requires libgcj.so.6 libgnome-java - 2.12.1-2.i386 requires libgcj.so.6 libgtk-java - 2.8.1-1.i386 requires libgcj.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.i386 requires libgcjawt.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 libvte-java - 0.11.11-6.i386 requires libgcj.so.6 lucene - 1.4.3-1jpp_7fc.i386 requires libgcj.so.6 lucene-demo - 1.4.3-1jpp_7fc.i386 requires libgcj.so.6 monolog - 1.8.6-1jpp_5fc.i386 requires libgcj.so.6 mx4j - 1:3.0.1-1jpp_5fc.i386 requires libgcj.so.6 nanoxml - 2.2.3-3jpp_3fc.i386 requires libgcj.so.6 nanoxml-lite - 2.2.3-3jpp_3fc.i386 requires libgcj.so.6 oldkilim - 1.1.3-2jpp_3fc.i386 requires libgcj.so.6 openoffice.org-core - 1:2.0.1-143.1.2.i386 requires libgcjawt.so.6 openoffice.org-core - 1:2.0.1-143.1.2.i386 requires libgcj.so.6 p6spy - 1.3-2jpp_3fc.i386 requires libgcj.so.6 regexp - 1.3-2jpp_3fc.i386 requires libgcj.so.6 struts - 1.2.4-2jpp_3fc.i386 requires libgcj.so.6 struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.i386 requires libgcj.so.6 systemtap - 0.5-2.i386 requires libdw.so.1(ELFUTILS_0.116) tetex-xdvi - 3.0-11.i386 requires libXm.so.3 tomcat5 - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 tomcat5-admin-webapps - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 tomcat5-jasper - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 tomcat5-webapps - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 xalan-j2 - 2.6.0-3jpp_4fc.i386 requires libgcj.so.6 xalan-j2-demo - 2.6.0-3jpp_4fc.i386 requires libgcj.so.6 xalan-j2-xsltc - 2.6.0-3jpp_4fc.i386 requires libgcj.so.6 xerces-j2 - 2.6.2-5jpp_2fc.i386 requires libgcj.so.6 xerces-j2-demo - 2.6.2-5jpp_2fc.i386 requires libgcj.so.6 xml-commons-apis - 1.0-0.b2.7jpp_3fc.i386 requires libgcj.so.6 xml-commons-which - 1.0-0.b2.7jpp_3fc.i386 requires libgcj.so.6 xpdf - 1:3.01-5.i386 requires libXm.so.3 Broken deps for ia64 ---------------------------------------------------------- anaconda - 10.90.16-1.ia64 requires anaconda-help carol - 1.8.9.3-1jpp_6fc.ia64 requires libgcj.so.6()(64bit) gnu-crypto - 2.0.1-1jpp_8fc.ia64 requires libgcj.so.6()(64bit) gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.ia64 requires libgcj.so.6()(64bit) gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.ia64 requires libgcj.so.6()(64bit) jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) jotm - 2.0.5-1jpp_3fc.ia64 requires libgcj.so.6()(64bit) jsch - 0.1.18-1jpp_2fc.ia64 requires libgcj.so.6()(64bit) libglade-java - 2.12.1-2.ia64 requires libgcj.so.6()(64bit) libgnome-java - 2.12.1-2.ia64 requires libgcj.so.6()(64bit) libgtk-java - 2.8.1-1.ia64 requires libgcj.so.6()(64bit) libsetrans - 0.1.11-2.ia64 requires libc.so.6(GLIBC_2.3.4) libsetrans - 0.1.11-2.ia64 requires libc.so.6(GLIBC_2.4) libsetrans - 0.1.11-2.ia64 requires libc.so.6(GLIBC_2.1) libsetrans - 0.1.11-2.ia64 requires libc.so.6(GLIBC_2.0) libsetrans - 0.1.11-2.ia64 requires libdl.so.2 libsetrans - 0.1.11-2.ia64 requires libc.so.6(GLIBC_2.1.3) libsetrans - 0.1.11-2.ia64 requires libc.so.6(GLIBC_2.3) libsetrans - 0.1.11-2.ia64 requires libc.so.6 libsetrans - 0.1.11-2.ia64 requires libselinux.so.1 libvte-java - 0.11.11-6.ia64 requires libgcj.so.6()(64bit) lucene - 1.4.3-1jpp_7fc.ia64 requires libgcj.so.6()(64bit) lucene-demo - 1.4.3-1jpp_7fc.ia64 requires libgcj.so.6()(64bit) monolog - 1.8.6-1jpp_5fc.ia64 requires libgcj.so.6()(64bit) mx4j - 1:3.0.1-1jpp_5fc.ia64 requires libgcj.so.6()(64bit) nanoxml - 2.2.3-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) nanoxml-lite - 2.2.3-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) oldkilim - 1.1.3-2jpp_3fc.ia64 requires libgcj.so.6()(64bit) p6spy - 1.3-2jpp_3fc.ia64 requires libgcj.so.6()(64bit) regexp - 1.3-2jpp_3fc.ia64 requires libgcj.so.6()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs struts - 1.2.4-2jpp_3fc.ia64 requires libgcj.so.6()(64bit) struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.ia64 requires libgcj.so.6()(64bit) systemtap - 0.5-2.ia64 requires libdw.so.1(ELFUTILS_0.116)(64bit) tetex-xdvi - 3.0-11.ia64 requires libXm.so.3()(64bit) tomcat5 - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) tomcat5-admin-webapps - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) tomcat5-jasper - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) tomcat5-webapps - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) xalan-j2 - 2.6.0-3jpp_4fc.ia64 requires libgcj.so.6()(64bit) xalan-j2-demo - 2.6.0-3jpp_4fc.ia64 requires libgcj.so.6()(64bit) xalan-j2-xsltc - 2.6.0-3jpp_4fc.ia64 requires libgcj.so.6()(64bit) xerces-j2 - 2.6.2-5jpp_2fc.ia64 requires libgcj.so.6()(64bit) xerces-j2-demo - 2.6.2-5jpp_2fc.ia64 requires libgcj.so.6()(64bit) xml-commons-apis - 1.0-0.b2.7jpp_3fc.ia64 requires libgcj.so.6()(64bit) xml-commons-which - 1.0-0.b2.7jpp_3fc.ia64 requires libgcj.so.6()(64bit) xpdf - 1:3.01-5.ia64 requires libXm.so.3()(64bit) Broken deps for ppc ---------------------------------------------------------- anaconda - 10.90.16-1.ppc requires anaconda-help carol - 1.8.9.3-1jpp_6fc.ppc requires libgcj.so.6 cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 eclipse-bugzilla - 1:0.1.1_fc-5.ppc requires libgcj.so.6 eclipse-cdt - 1:3.0.1-1jpp_1fc.ppc requires libgcj.so.6 eclipse-changelog - 1:2.0.1_fc-22.ppc requires libgcj.so.6 eclipse-ecj - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-jdt - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-pde - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-platform - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-pydev - 1:0.9.3_fc-12.ppc requires libgcj.so.6 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 gnu-crypto - 2.0.1-1jpp_8fc.ppc requires libgcj.so.6 gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.ppc requires libgcj.so.6 gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.ppc requires libgcj.so.6 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jotm - 2.0.5-1jpp_3fc.ppc requires libgcj.so.6 jsch - 0.1.18-1jpp_2fc.ppc requires libgcj.so.6 libglade-java - 2.12.1-2.ppc requires libgcj.so.6 libgnome-java - 2.12.1-2.ppc requires libgcj.so.6 libgtk-java - 2.8.1-1.ppc requires libgcj.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.ppc requires libgcjawt.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 libvte-java - 0.11.11-6.ppc requires libgcj.so.6 lucene - 1.4.3-1jpp_7fc.ppc requires libgcj.so.6 lucene-demo - 1.4.3-1jpp_7fc.ppc requires libgcj.so.6 monolog - 1.8.6-1jpp_5fc.ppc requires libgcj.so.6 mx4j - 1:3.0.1-1jpp_5fc.ppc requires libgcj.so.6 nanoxml - 2.2.3-3jpp_3fc.ppc requires libgcj.so.6 nanoxml-lite - 2.2.3-3jpp_3fc.ppc requires libgcj.so.6 oldkilim - 1.1.3-2jpp_3fc.ppc requires libgcj.so.6 openoffice.org-core - 1:2.0.1-143.1.2.ppc requires libgcjawt.so.6 openoffice.org-core - 1:2.0.1-143.1.2.ppc requires libgcj.so.6 p6spy - 1.3-2jpp_3fc.ppc requires libgcj.so.6 regexp - 1.3-2jpp_3fc.ppc requires libgcj.so.6 struts - 1.2.4-2jpp_3fc.ppc requires libgcj.so.6 struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.ppc requires libgcj.so.6 systemtap - 0.5-2.ppc requires libdw.so.1(ELFUTILS_0.116) tetex-xdvi - 3.0-11.ppc requires libXm.so.3 tomcat5 - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 tomcat5-admin-webapps - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 tomcat5-jasper - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 tomcat5-webapps - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 xalan-j2 - 2.6.0-3jpp_4fc.ppc requires libgcj.so.6 xalan-j2-demo - 2.6.0-3jpp_4fc.ppc requires libgcj.so.6 xalan-j2-xsltc - 2.6.0-3jpp_4fc.ppc requires libgcj.so.6 xerces-j2 - 2.6.2-5jpp_2fc.ppc requires libgcj.so.6 xerces-j2-demo - 2.6.2-5jpp_2fc.ppc requires libgcj.so.6 xml-commons-apis - 1.0-0.b2.7jpp_3fc.ppc requires libgcj.so.6 xml-commons-which - 1.0-0.b2.7jpp_3fc.ppc requires libgcj.so.6 xpdf - 1:3.01-5.ppc requires libXm.so.3 Broken deps for ppc64 ---------------------------------------------------------- anaconda - 10.90.16-1.ppc64 requires anaconda-help carol - 1.8.9.3-1jpp_6fc.ppc64 requires libgcj.so.6()(64bit) cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 gnu-crypto - 2.0.1-1jpp_8fc.ppc64 requires libgcj.so.6()(64bit) gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.ppc64 requires libgcj.so.6()(64bit) gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.ppc64 requires libgcj.so.6()(64bit) jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) jotm - 2.0.5-1jpp_3fc.ppc64 requires libgcj.so.6()(64bit) jsch - 0.1.18-1jpp_2fc.ppc64 requires libgcj.so.6()(64bit) libglade-java - 2.12.1-2.ppc64 requires libgcj.so.6()(64bit) libgnome-java - 2.12.1-2.ppc64 requires libgcj.so.6()(64bit) libgtk-java - 2.8.1-1.ppc64 requires libgcj.so.6()(64bit) libsetrans - 0.1.11-2.ppc64 requires libc.so.6(GLIBC_2.3.4) libsetrans - 0.1.11-2.ppc64 requires libc.so.6(GLIBC_2.4) libsetrans - 0.1.11-2.ppc64 requires libc.so.6(GLIBC_2.1) libsetrans - 0.1.11-2.ppc64 requires libc.so.6(GLIBC_2.0) libsetrans - 0.1.11-2.ppc64 requires libdl.so.2 libsetrans - 0.1.11-2.ppc64 requires libc.so.6(GLIBC_2.1.3) libsetrans - 0.1.11-2.ppc64 requires libc.so.6(GLIBC_2.3) libsetrans - 0.1.11-2.ppc64 requires libc.so.6 libsetrans - 0.1.11-2.ppc64 requires libselinux.so.1 libvte-java - 0.11.11-6.ppc64 requires libgcj.so.6()(64bit) lucene - 1.4.3-1jpp_7fc.ppc64 requires libgcj.so.6()(64bit) lucene-demo - 1.4.3-1jpp_7fc.ppc64 requires libgcj.so.6()(64bit) monolog - 1.8.6-1jpp_5fc.ppc64 requires libgcj.so.6()(64bit) mx4j - 1:3.0.1-1jpp_5fc.ppc64 requires libgcj.so.6()(64bit) nanoxml - 2.2.3-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) nanoxml-lite - 2.2.3-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) oldkilim - 1.1.3-2jpp_3fc.ppc64 requires libgcj.so.6()(64bit) p6spy - 1.3-2jpp_3fc.ppc64 requires libgcj.so.6()(64bit) regexp - 1.3-2jpp_3fc.ppc64 requires libgcj.so.6()(64bit) struts - 1.2.4-2jpp_3fc.ppc64 requires libgcj.so.6()(64bit) struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.ppc64 requires libgcj.so.6()(64bit) tetex-xdvi - 3.0-11.ppc64 requires libXm.so.3()(64bit) tomcat5 - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) tomcat5-admin-webapps - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) tomcat5-jasper - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) tomcat5-webapps - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) xalan-j2 - 2.6.0-3jpp_4fc.ppc64 requires libgcj.so.6()(64bit) xalan-j2-demo - 2.6.0-3jpp_4fc.ppc64 requires libgcj.so.6()(64bit) xalan-j2-xsltc - 2.6.0-3jpp_4fc.ppc64 requires libgcj.so.6()(64bit) xerces-j2 - 2.6.2-5jpp_2fc.ppc64 requires libgcj.so.6()(64bit) xerces-j2-demo - 2.6.2-5jpp_2fc.ppc64 requires libgcj.so.6()(64bit) xml-commons-apis - 1.0-0.b2.7jpp_3fc.ppc64 requires libgcj.so.6()(64bit) xml-commons-which - 1.0-0.b2.7jpp_3fc.ppc64 requires libgcj.so.6()(64bit) xpdf - 1:3.01-5.ppc64 requires libXm.so.3()(64bit) Broken deps for s390 ---------------------------------------------------------- anaconda - 10.90.16-1.s390 requires anaconda-help carol - 1.8.9.3-1jpp_6fc.s390 requires libgcj.so.6 gnu-crypto - 2.0.1-1jpp_8fc.s390 requires libgcj.so.6 gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.s390 requires libgcj.so.6 gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.s390 requires libgcj.so.6 jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jotm - 2.0.5-1jpp_3fc.s390 requires libgcj.so.6 jsch - 0.1.18-1jpp_2fc.s390 requires libgcj.so.6 libglade-java - 2.12.1-2.s390 requires libgcj.so.6 libgnome-java - 2.12.1-2.s390 requires libgcj.so.6 libgtk-java - 2.8.1-1.s390 requires libgcj.so.6 libvte-java - 0.11.11-6.s390 requires libgcj.so.6 lucene - 1.4.3-1jpp_7fc.s390 requires libgcj.so.6 lucene-demo - 1.4.3-1jpp_7fc.s390 requires libgcj.so.6 monolog - 1.8.6-1jpp_5fc.s390 requires libgcj.so.6 mx4j - 1:3.0.1-1jpp_5fc.s390 requires libgcj.so.6 nanoxml - 2.2.3-3jpp_3fc.s390 requires libgcj.so.6 nanoxml-lite - 2.2.3-3jpp_3fc.s390 requires libgcj.so.6 oldkilim - 1.1.3-2jpp_3fc.s390 requires libgcj.so.6 p6spy - 1.3-2jpp_3fc.s390 requires libgcj.so.6 regexp - 1.3-2jpp_3fc.s390 requires libgcj.so.6 struts - 1.2.4-2jpp_3fc.s390 requires libgcj.so.6 struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.s390 requires libgcj.so.6 tetex-xdvi - 3.0-11.s390 requires libXm.so.3 tomcat5 - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 tomcat5-admin-webapps - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 tomcat5-jasper - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 tomcat5-webapps - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 xalan-j2 - 2.6.0-3jpp_4fc.s390 requires libgcj.so.6 xalan-j2-demo - 2.6.0-3jpp_4fc.s390 requires libgcj.so.6 xalan-j2-xsltc - 2.6.0-3jpp_4fc.s390 requires libgcj.so.6 xerces-j2 - 2.6.2-5jpp_2fc.s390 requires libgcj.so.6 xerces-j2-demo - 2.6.2-5jpp_2fc.s390 requires libgcj.so.6 xml-commons-apis - 1.0-0.b2.7jpp_3fc.s390 requires libgcj.so.6 xml-commons-which - 1.0-0.b2.7jpp_3fc.s390 requires libgcj.so.6 xpdf - 1:3.01-5.s390 requires libXm.so.3 Broken deps for s390x ---------------------------------------------------------- anaconda - 10.90.16-1.s390x requires anaconda-help carol - 1.8.9.3-1jpp_6fc.s390x requires libgcj.so.6()(64bit) gnu-crypto - 2.0.1-1jpp_8fc.s390x requires libgcj.so.6()(64bit) gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.s390x requires libgcj.so.6()(64bit) gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.s390x requires libgcj.so.6()(64bit) jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) jotm - 2.0.5-1jpp_3fc.s390x requires libgcj.so.6()(64bit) jsch - 0.1.18-1jpp_2fc.s390x requires libgcj.so.6()(64bit) libgconf-java - 2.12.0-2.s390x requires libgcj.so.6()(64bit) libgconf-java - 2.12.0-2.s390x requires libglibjava-0.2.so()(64bit) libgconf-java - 2.12.0-2.s390x requires libglibjni-0.2.so()(64bit) libgconf-java - 2.12.0-2.s390x requires libcairojava-1.0.so()(64bit) libglade-java - 2.12.0-5.s390x requires libgcj.so.6()(64bit) libglade-java - 2.12.0-5.s390x requires libglibjava-0.2.so()(64bit) libglade-java - 2.12.0-5.s390x requires libglibjni-0.2.so()(64bit) libglade-java - 2.12.0-5.s390x requires libcairojava-1.0.so()(64bit) libgnome-java - 2.12.0-2.s390x requires libgcj.so.6()(64bit) libgnome-java - 2.12.0-2.s390x requires libglibjava-0.2.so()(64bit) libgnome-java - 2.12.0-2.s390x requires libglibjni-0.2.so()(64bit) libgnome-java - 2.12.0-2.s390x requires libcairojava-1.0.so()(64bit) libgtk-java - 2.8.0-7.s390x requires libgcj.so.6()(64bit) libgtk-java - 2.8.0-7.s390x requires libglibjava-0.2.so()(64bit) libgtk-java - 2.8.0-7.s390x requires libglibjni-0.2.so()(64bit) libvte-java - 0.11.11-6.s390x requires libgcj.so.6()(64bit) libvte-java - 0.11.11-6.s390x requires libglibjava-0.2.so()(64bit) libvte-java - 0.11.11-6.s390x requires libglibjni-0.2.so()(64bit) libvte-java - 0.11.11-6.s390x requires libcairojava-1.0.so()(64bit) lucene - 1.4.3-1jpp_7fc.s390x requires libgcj.so.6()(64bit) lucene-demo - 1.4.3-1jpp_7fc.s390x requires libgcj.so.6()(64bit) monolog - 1.8.6-1jpp_5fc.s390x requires libgcj.so.6()(64bit) mx4j - 1:3.0.1-1jpp_5fc.s390x requires libgcj.so.6()(64bit) nanoxml - 2.2.3-3jpp_3fc.s390x requires libgcj.so.6()(64bit) nanoxml-lite - 2.2.3-3jpp_3fc.s390x requires libgcj.so.6()(64bit) oldkilim - 1.1.3-2jpp_3fc.s390x requires libgcj.so.6()(64bit) p6spy - 1.3-2jpp_3fc.s390x requires libgcj.so.6()(64bit) regexp - 1.3-2jpp_3fc.s390x requires libgcj.so.6()(64bit) struts - 1.2.4-2jpp_3fc.s390x requires libgcj.so.6()(64bit) struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.s390x requires libgcj.so.6()(64bit) tetex-xdvi - 3.0-11.s390x requires libXm.so.3()(64bit) tomcat5 - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) tomcat5-admin-webapps - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) tomcat5-jasper - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) tomcat5-webapps - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) xalan-j2 - 2.6.0-3jpp_4fc.s390x requires libgcj.so.6()(64bit) xalan-j2-demo - 2.6.0-3jpp_4fc.s390x requires libgcj.so.6()(64bit) xalan-j2-xsltc - 2.6.0-3jpp_4fc.s390x requires libgcj.so.6()(64bit) xerces-j2 - 2.6.2-5jpp_2fc.s390x requires libgcj.so.6()(64bit) xerces-j2-demo - 2.6.2-5jpp_2fc.s390x requires libgcj.so.6()(64bit) xml-commons-apis - 1.0-0.b2.7jpp_3fc.s390x requires libgcj.so.6()(64bit) xml-commons-which - 1.0-0.b2.7jpp_3fc.s390x requires libgcj.so.6()(64bit) xpdf - 1:3.01-5.s390x requires libXm.so.3()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 anaconda - 10.90.16-1.x86_64 requires anaconda-help carol - 1.8.9.3-1jpp_6fc.x86_64 requires libgcj.so.6()(64bit) cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 eclipse-bugzilla - 1:0.1.1_fc-5.x86_64 requires libgcj.so.6()(64bit) eclipse-cdt - 1:3.0.1-1jpp_1fc.x86_64 requires libgcj.so.6()(64bit) eclipse-changelog - 1:2.0.1_fc-22.x86_64 requires libgcj.so.6()(64bit) eclipse-ecj - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-jdt - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-pde - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-platform - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-pydev - 1:0.9.3_fc-12.x86_64 requires libgcj.so.6()(64bit) gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 gnu-crypto - 2.0.1-1jpp_8fc.x86_64 requires libgcj.so.6()(64bit) gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.x86_64 requires libgcj.so.6()(64bit) gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.x86_64 requires libgcj.so.6()(64bit) jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jotm - 2.0.5-1jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jsch - 0.1.18-1jpp_2fc.x86_64 requires libgcj.so.6()(64bit) libglade-java - 2.12.1-2.x86_64 requires libgcj.so.6()(64bit) libgnome-java - 2.12.1-2.x86_64 requires libgcj.so.6()(64bit) libgtk-java - 2.8.1-1.x86_64 requires libgcj.so.6()(64bit) libswt3-gtk2 - 1:3.1.1-1jpp_9fc.x86_64 requires libgcjawt.so.6()(64bit) libswt3-gtk2 - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) libvte-java - 0.11.11-6.x86_64 requires libgcj.so.6()(64bit) lucene - 1.4.3-1jpp_7fc.x86_64 requires libgcj.so.6()(64bit) lucene-demo - 1.4.3-1jpp_7fc.x86_64 requires libgcj.so.6()(64bit) monolog - 1.8.6-1jpp_5fc.x86_64 requires libgcj.so.6()(64bit) mx4j - 1:3.0.1-1jpp_5fc.x86_64 requires libgcj.so.6()(64bit) nanoxml - 2.2.3-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) nanoxml-lite - 2.2.3-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) oldkilim - 1.1.3-2jpp_3fc.x86_64 requires libgcj.so.6()(64bit) openoffice.org-core - 1:2.0.1-143.1.2.i386 requires libgcjawt.so.6 openoffice.org-core - 1:2.0.1-143.1.2.i386 requires libgcj.so.6 p6spy - 1.3-2jpp_3fc.x86_64 requires libgcj.so.6()(64bit) regexp - 1.3-2jpp_3fc.x86_64 requires libgcj.so.6()(64bit) struts - 1.2.4-2jpp_3fc.x86_64 requires libgcj.so.6()(64bit) struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.x86_64 requires libgcj.so.6()(64bit) systemtap - 0.5-2.x86_64 requires libdw.so.1(ELFUTILS_0.116)(64bit) tetex-xdvi - 3.0-11.x86_64 requires libXm.so.3()(64bit) tomcat5 - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) tomcat5-admin-webapps - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) tomcat5-jasper - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) tomcat5-webapps - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) xalan-j2 - 2.6.0-3jpp_4fc.x86_64 requires libgcj.so.6()(64bit) xalan-j2-demo - 2.6.0-3jpp_4fc.x86_64 requires libgcj.so.6()(64bit) xalan-j2-xsltc - 2.6.0-3jpp_4fc.x86_64 requires libgcj.so.6()(64bit) xerces-j2 - 2.6.2-5jpp_2fc.x86_64 requires libgcj.so.6()(64bit) xerces-j2-demo - 2.6.2-5jpp_2fc.x86_64 requires libgcj.so.6()(64bit) xml-commons-apis - 1.0-0.b2.7jpp_3fc.x86_64 requires libgcj.so.6()(64bit) xml-commons-which - 1.0-0.b2.7jpp_3fc.x86_64 requires libgcj.so.6()(64bit) xpdf - 1:3.01-5.x86_64 requires libXm.so.3()(64bit) From che666 at gmail.com Mon Dec 12 12:34:36 2005 From: che666 at gmail.com (Rudolf Kastl) Date: Mon, 12 Dec 2005 13:34:36 +0100 Subject: gstreamer 0.10 In-Reply-To: <1134100748.11873.9.camel@localhost.localdomain> References: <1134100748.11873.9.camel@localhost.localdomain> Message-ID: 2005/12/9, John (J5) Palmieri : > > On Thu, 2005-12-08 at 13:54 -0600, Jason Dravet wrote: > > Is gstreamer 0.10 going to be in FC5T2? > > That depends if we have applications that are ported to it. As it is I > would say that it should go into extras first. If a significant portion > of core apps start depending on 0.10 then we can pull it in. > > -- > John (J5) Palmieri > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > bmp(x) supports it aswell. -------------- next part -------------- An HTML attachment was scrubbed... URL: From linville at redhat.com Mon Dec 12 17:55:11 2005 From: linville at redhat.com (John W. Linville) Date: Mon, 12 Dec 2005 12:55:11 -0500 Subject: sky2 and hard drive performance In-Reply-To: <20051212030418.GA22877@redhat.com> References: <439C85D0.4060804@cygnusx-1.org> <1134344072.10234.36.camel@localhost.localdomain> <439CE62F.9050609@osdl.org> <20051212030418.GA22877@redhat.com> Message-ID: <20051212175511.GG29015@redhat.com> On Sun, Dec 11, 2005 at 10:04:18PM -0500, John W. Linville wrote: > On Sun, Dec 11, 2005 at 06:53:35PM -0800, Stephen Hemminger wrote: > > Doesn't anybody read the mailing lists... There was a missing interrupt > > clear that was fixed about 1 day later. > > That patch didn't make it into FC4.netdev.4. I'm spinning FC4.netdev.5 > now, w/ just that patch added. ...and it is now available: http://people.redhat.com/linville/kernels/fedora-netdev/ Thanks! John -- John W. Linville linville at redhat.com From linville at redhat.com Mon Dec 12 17:58:59 2005 From: linville at redhat.com (John W. Linville) Date: Mon, 12 Dec 2005 12:58:59 -0500 Subject: sky2 and hard drive performance In-Reply-To: <439CBD11.8030202@cygnusx-1.org> References: <439C85D0.4060804@cygnusx-1.org> <1134344072.10234.36.camel@localhost.localdomain> <439CBD11.8030202@cygnusx-1.org> Message-ID: <20051212175859.GH29015@redhat.com> On Sun, Dec 11, 2005 at 03:58:09PM -0800, Nathan Grennan wrote: > I just downloaded the latest sk98lin driver from the Syskonnect site. > I compiled it against kernel-2.6.14-1.1644_FC4.x86_64, and loaded it. It > seems to work, it doesn't crash the system on reactivation, and doesn't > degrade my hard drive performance. Lovely. However, unless you would prefer to continue executing that process it would be better if you could stick with sky2. I'm confident that sk98lin will not be updated either in Fedora or upstream kernels anytime soon. > I had avoided sk98lin from the Syskonnect site, because of messages I > had found that said it was poorly written and that sky2 was supposed to > be well written. Maybe it isn't written to the linux kernel standards, > but it at least works better than the latest version of sky2. I think I > will keep my eye on sky2, but use sk98lin for now. Perhaps you should give sky2 another look. FC4.netdev.5 has the patch which is likely to correct the problem you observed. http://people.redhat.com/linville/kernels/fedora-netdev/ Please give that a try and post whether or not it resovles the issue for you. Thanks! John -- John W. Linville linville at redhat.com From Spurred_On at earthlink.net Mon Dec 12 19:54:06 2005 From: Spurred_On at earthlink.net (Tony) Date: Mon, 12 Dec 2005 12:54:06 -0700 Subject: Rawhide mouse slow movement control Message-ID: <6.2.3.4.2.20051212110447.0314b170@mail.bresnan.net> Howdy I'd like to suggest a capability to be included in the Rawhide project. The request comes from my attempt to setup a PS/2 Kensington Expert Mouse on a Fedora system. The Kensington Expert Mouse is a trackball designed for Windows systems. The trackball hardware is not an issue. Setting up the Kensington mouse using the standard gnome mouse program, the trackball maneuvers the cursor like a normal mouse without problem. The issue is a missing software control which is not available in the standard mouse preferences program but which is available in the Kensington Mouseworks program, a Windows specific program not ported to Linux. Without the Mouseworks program installed on a system, the trackball works the same in either a Windows or Linux environment. With the Kensington Mouseworks program it is possible to set up entirely different parameters for how the cursor is accelerated when the mouse is moved slowly versus when it is moved fast. This allows a user to zip the cursor to an area on the screen and then have slow, precision control once there, as when editing a picture or selecting any small item on the screen. This capability becomes more important as screen resolutions increase and items on screen become smaller and harder to pinpoint exactly. Such fine control would be beneficial for use with any type of mouse and should be manufacturer independent. From within the present mouse program a Fedora user can adjust the acceleration of the cursor movement globally only, restricted to using a single slider button. Neither is there the ability for the program to detect when the mouse is being moved slowly. In the Mouseworks program there is a box which must be checked to access the fine control parameters. If left unchecked, only the standard acceleration control is available and the fine controls are grayed out. If checked, the Mouseworks program makes two additional slider controls available; one for when the mouse is moved fast and one for when it is moved slow. Once selected, when the program detects that the mouse is being moved slowly it alters the acceleration of the cursor according to user preferences. I don't know at what threshold the program determines the movement to be slow. It seems to be a gradual change, not a sudden shift from super fast to super slow. This capability should not be available for use with a finger pad on a laptop. Personally, I use a Wacom tablet, and, like a finger pad, when I move the stylus slowly the cursor moves slowly and precisely. There would be no use for such additional control on a tablet or a finger pad, and the option should be grayed out unless the system detects an external mouse connection, and then it should only be applied to an external mouse. Tony From seandarcy2 at gmail.com Mon Dec 12 21:11:48 2005 From: seandarcy2 at gmail.com (sean) Date: Mon, 12 Dec 2005 16:11:48 -0500 Subject: yum and yum-utils out of sync? Message-ID: yumdownloader --help Traceback (most recent call last): File "/usr/bin/yumdownloader", line 27, in ? from yum.packages import parsePackages, returnBestPackages ImportError: cannot import name returnBestPackages yum-2.5.0-0.20051210 yum-utils-0.3.1-1.fc5 Any suggestions? sean From jspaleta at gmail.com Mon Dec 12 21:26:29 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Mon, 12 Dec 2005 16:26:29 -0500 Subject: yum and yum-utils out of sync? In-Reply-To: References: Message-ID: <604aa7910512121326g74c7d55ctf4d20c0208250575@mail.gmail.com> On 12/12/05, sean wrote: > Any suggestions? revert back to a 2.4.x yum until the Extras packages are ported forward to work with yum 2.5 or hell freezes over and Core reverts yum back to 2.4. You do keep your rawhide downloads cached right? And just a heads up, it appears that the yum 2.5 in Core doesn't play well with the mock or yumex in Extras either. -jef"without a working repoquery and mock on my rawhide box, my life seems tragically without meaning or purpose"spaleta From fedora-devel-list at cygnusx-1.org Mon Dec 12 22:58:32 2005 From: fedora-devel-list at cygnusx-1.org (Nathan Grennan) Date: Mon, 12 Dec 2005 14:58:32 -0800 Subject: sky2 and hard drive performance In-Reply-To: <20051212175859.GH29015@redhat.com> References: <439C85D0.4060804@cygnusx-1.org> <1134344072.10234.36.camel@localhost.localdomain> <439CBD11.8030202@cygnusx-1.org> <20051212175859.GH29015@redhat.com> Message-ID: <439E0098.6050905@cygnusx-1.org> John W. Linville wrote: > > Perhaps you should give sky2 another look. FC4.netdev.5 has the > patch which is likely to correct the problem you observed. > > http://people.redhat.com/linville/kernels/fedora-netdev/ > > Please give that a try and post whether or not it resovles the issue > for you. > As I said I would keep my eye on sky2. I just rebooted to netdev.5. Both issues I have having before with netdev.4 seem to be fixed. Thank you very much. :) From seandarcy2 at gmail.com Mon Dec 12 23:53:30 2005 From: seandarcy2 at gmail.com (sean) Date: Mon, 12 Dec 2005 18:53:30 -0500 Subject: yum and yum-utils out of sync? In-Reply-To: <604aa7910512121326g74c7d55ctf4d20c0208250575@mail.gmail.com> References: <604aa7910512121326g74c7d55ctf4d20c0208250575@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > On 12/12/05, sean wrote: > >>Any suggestions? > > > revert back to a 2.4.x yum until the Extras packages are ported > forward to work with yum 2.5 or hell freezes over and Core reverts yum > back to 2.4. You do keep your rawhide downloads cached right? > > And just a heads up, it appears that the yum 2.5 in Core doesn't play > well with the mock or yumex in Extras either. > > -jef"without a working repoquery and mock on my rawhide box, my life > seems tragically without meaning or purpose"spaleta > I'm back to 2.4.3. thanks sean From patmans at us.ibm.com Tue Dec 13 01:59:17 2005 From: patmans at us.ibm.com (Patrick Mansfield) Date: Mon, 12 Dec 2005 17:59:17 -0800 Subject: install problem with fc devel as of dec 10 Message-ID: <20051213015917.GA14560@us.ibm.com> Has anyone been able to do a full install recently with fc devel? My system is not rebooting after the rpm install step completes. I've searched recent bugs and found nothing ... I've booted install kernels via both copies of the pxeboot images (copied to my local disk) and then via CDROM. I'm then running over a serial line for stage1, with nfs and vnc install options. System is an older x86 IBM system, installing to storage attached via SERVERAID/ips SCSI HBA. I tried FC devel based on a rsync from saturday (dec 10), and again today (dec 12) with apparently the same result. On Saturday, I tried to just "init 6" in the shell (anaconda shell escape), and first boot failed, I assume the install was not complete, so that would explain the boot failure, not including further details. Today, I was trying to debug some via the shell, but got stuck when I tried to ping (was going to ping the network and then try to scp information out). Anyone know how to kill a foreground process in the anaconda shell??? I don't have full dmesg output - booted from CDROM on VGA console, then switched to the serial line. The main thing I notice is this dmesg output: audit(1134461372.947:68): avc: denied { execmem } for pid=9577 comm="grub" scontext=system_u:system_r:anaconda_t:s0 tcontext=system_u:system_r:anaconda_t:s0 tclass=process I would think something would have been output to the gui or serial line if grub failed to run/install. I can try installing again, installs are taking about 3 hours or so for me (older x86 box ... no network/pxe boot), the dependency checking alone seems to take 20 minutes or so. So, I can re-run and get more information, but it will take some time. Below is output saved during the install, before the "ping" stopped me, including: console (serial line) output last seen tail -111 of /tmp/anaconda.log dmesg | tail -11 Thanks ... ====================================================================== Last output on the console/serial line before it seems to hang: sh-3.00# * GRUB commands: * root (hd0,0) * install /grub/stage1 d (hd0) /grub/stage2 p (hd0,0)/grub/grub.conf ====================================================================== tail -111 of /tmp/anaconda.log: 23:33:40 DEBUG : Member: libXdmcp.i386 0-0.99.1-2 - u 23:33:40 DEBUG : Adding Package libXdmcp - 0.99.1-2.i386 in mode u 23:33:40 DEBUG : Member: gnome-games.i386 1-2.13.2-1.1 - u 23:33:40 DEBUG : Adding Package gnome-games - 1:2.13.2-1.1.i386 in mode u 23:33:40 DEBUG : Member: python-numeric.i386 0-23.7-2 - u 23:33:40 DEBUG : Adding Package python-numeric - 23.7-2.i386 in mode u 23:33:40 DEBUG : Member: atk.i386 0-1.10.3-1.1 - u 23:33:40 DEBUG : Adding Package atk - 1.10.3-1.1.i386 in mode u 23:33:40 DEBUG : Member: dbus-x11.i386 0-0.60-1.1 - u 23:33:40 DEBUG : Adding Package dbus-x11 - 0.60-1.1.i386 in mode u 23:33:40 DEBUG : Member: firefox.i386 0-1.5-1.1 - u 23:33:40 DEBUG : Adding Package firefox - 1.5-1.1.i386 in mode u 23:33:40 DEBUG : Member: xorg-x11-xauth.i386 1-0.99.2-1 - u 23:33:41 DEBUG : Adding Package xorg-x11-xauth - 1:0.99.2-1.i386 in mode u 23:33:41 DEBUG : Member: freetype-devel.i386 0-2.1.10-5.1 - u 23:33:41 DEBUG : Adding Package freetype-devel - 2.1.10-5.1.i386 in mode u 23:33:41 DEBUG : Member: libXau.i386 0-0.99.1-2 - u 23:33:41 DEBUG : Adding Package libXau - 0.99.1-2.i386 in mode u 23:33:41 DEBUG : Member: byacc.i386 0-1.9-29.1 - u 23:33:41 DEBUG : Adding Package byacc - 1.9-29.1.i386 in mode u 23:33:41 DEBUG : Member: module-init-tools.i386 0-3.2-0.pre9.1 - u 23:33:41 DEBUG : Adding Package module-init-tools - 3.2-0.pre9.1.i386 in mode u 23:33:41 DEBUG : Member: file-roller.i386 0-2.13.1-1.1 - u 23:33:41 DEBUG : Adding Package file-roller - 2.13.1-1.1.i386 in mode u 23:33:41 DEBUG : Member: ypbind.i386 3-1.17.2-5 - u 23:33:41 DEBUG : Adding Package ypbind - 3:1.17.2-5.i386 in mode u 23:33:41 DEBUG : Member: sudo.i386 0-1.6.8p12-1 - u 23:33:41 DEBUG : Adding Package sudo - 1.6.8p12-1.i386 in mode u 23:33:41 DEBUG : Member: xrestop.i386 0-0.2-6 - u 23:33:41 DEBUG : Adding Package xrestop - 0.2-6.i386 in mode u 23:33:41 DEBUG : Member: sgml-common.noarch 0-0.6.3-17 - u 23:33:41 DEBUG : Adding Package sgml-common - 0.6.3-17.noarch in mode u 23:33:41 DEBUG : Member: pinfo.i386 0-0.6.8-11 - u 23:33:41 DEBUG : Adding Package pinfo - 0.6.8-11.i386 in mode u 23:33:41 DEBUG : Member: fedora-release.noarch 0-4-99.rawhide - u 23:33:41 DEBUG : Adding Package fedora-release - 4-99.rawhide.noarch in mode u 23:33:41 DEBUG : Member: xorg-x11-drv-ur98.i386 0-1.0.0.2-1 - u 23:33:41 DEBUG : Adding Package xorg-x11-drv-ur98 - 1.0.0.2-1.i386 in mode u 23:33:41 DEBUG : Member: libtheora.i386 0-1.0alpha5-1.1 - u 23:33:41 DEBUG : Adding Package libtheora - 1.0alpha5-1.1.i386 in mode u 23:33:41 DEBUG : Member: xorg-x11-font-utils.i386 1-0.99.1-1 - u 23:33:42 DEBUG : Adding Package xorg-x11-font-utils - 1:0.99.1-1.i386 in mode u 23:33:42 DEBUG : Member: libXxf86misc.i386 0-0.99.1-2 - u 23:33:42 DEBUG : Adding Package libXxf86misc - 0.99.1-2.i386 in mode u 23:33:42 DEBUG : Member: sound-juicer.i386 0-2.13.1-2.1 - u 23:33:42 DEBUG : Adding Package sound-juicer - 2.13.1-2.1.i386 in mode u 23:33:42 DEBUG : Member: pm-utils.i386 0-0.07-4 - u 23:33:42 DEBUG : Adding Package pm-utils - 0.07-4.i386 in mode u 23:37:17 INFO : Initial install time estimate = 32.4141617107 00:09:17 INFO : Actual install time = 34.6414714495 00:09:17 INFO : Actual install time = 34.6467892329 00:09:18 INFO : moving (1) to step postinstallconfig 00:09:18 INFO : self.hostname = elm3a49 00:09:18 INFO : moving (1) to step writeconfig 00:09:18 INFO : Writing main configuration 00:09:30 INFO : moving (1) to step firstboot 00:09:30 INFO : moving (1) to step instbootloader 00:09:33 INFO : moving (1) to step writexconfig 00:09:33 INFO : Writing X configuration 00:09:33 INFO : moving (1) to step writeksconfig 00:09:33 INFO : Writing autokickstart file 00:09:33 INFO : moving (1) to step setfilecon 00:09:33 INFO : setting SELinux contexts for anaconda created files 00:09:33 INFO : set fc of /etc/rpm/platform to system_u:object_r:etc_t:s0 00:09:33 WARNING : /etc/rpm/macros doesn't exist 00:09:33 WARNING : /etc/lilo.conf.anaconda doesn't exist 00:09:33 INFO : set fc of /etc/mtab to system_u:object_r:etc_runtime_t:s0 00:09:33 INFO : set fc of /etc/fstab to system_u:object_r:etc_t:s0 00:09:33 INFO : set fc of /etc/resolv.conf to system_u:object_r:net_conf_t:s0 00:09:33 INFO : set fc of /etc/modprobe.conf to system_u:object_r:modules_conf_t:s0 00:09:33 WARNING : /etc/modprobe.conf~ doesn't exist 00:09:33 INFO : set fc of /var/log/wtmp to system_u:object_r:wtmp_t:s0 00:09:34 INFO : set fc of /var/run/utmp to system_u:object_r:initrc_var_run_t:s0 00:09:34 INFO : set fc of /dev/log to system_u:object_r:devlog_t:s0 00:09:34 INFO : set fc of /var/lib/rpm to system_u:object_r:rpm_var_lib_t:s0 00:09:34 INFO : set fc of / to system_u:object_r:root_t:s0 00:09:34 WARNING : /etc/raidtab doesn't exist 00:09:34 WARNING : /etc/mdadm.conf doesn't exist 00:09:34 INFO : set fc of /var/lib/rpm/Filemd5s to system_u:object_r:rpm_var_lib_t:s0 00:09:34 INFO : set fc of /var/lib/rpm/Installtid to system_u:object_r:rpm_var_lib_t:s0 00:09:34 INFO : set fc of /var/lib/rpm/Pubkeys to system_u:object_r:rpm_var_lib_t:s0 00:09:34 INFO : set fc of /var/lib/rpm/Basenames to system_u:object_r:rpm_var_lib_t:s0 00:09:34 INFO : set fc of /var/lib/rpm/Conflictname to system_u:object_r:rpm_var_lib_t:s0 00:09:34 INFO : set fc of /var/lib/rpm/Provideversion to system_u:object_r:rpm_var_lib_t:s0 00:09:34 INFO : set fc of /var/lib/rpm/Group to system_u:object_r:rpm_var_lib_t:s0 00:09:34 INFO : set fc of /var/lib/rpm/Sha1header to system_u:object_r:rpm_var_lib_t:s0 00:09:34 INFO : set fc of /var/lib/rpm/__db.001 to system_u:object_r:rpm_var_lib_t:s0 00:09:34 INFO : set fc of /var/lib/rpm/Name to system_u:object_r:rpm_var_lib_t:s0 00:09:34 INFO : set fc of /var/lib/rpm/__db.000 to system_u:object_r:rpm_var_lib_t:s0 00:09:34 INFO : set fc of /var/lib/rpm/__db.002 to system_u:object_r:rpm_var_lib_t:s0 00:09:34 INFO : set fc of /var/lib/rpm/Requirename to system_u:object_r:rpm_var_lib_t:s0 00:09:34 INFO : set fc of /var/lib/rpm/Packages to system_u:object_r:rpm_var_lib_t:s0 00:09:34 INFO : set fc of /var/lib/rpm/Triggername to system_u:object_r:rpm_var_lib_t:s0 00:09:34 INFO : set fc of /var/lib/rpm/Providename to system_u:object_r:rpm_var_lib_t:s0 00:09:34 INFO : set fc of /var/lib/rpm/__db.003 to system_u:object_r:rpm_var_lib_t:s0 00:09:34 INFO : set fc of /var/lib/rpm/Requireversion to system_u:object_r:rpm_var_lib_t:s0 00:09:34 INFO : set fc of /var/lib/rpm/Dirnames to system_u:object_r:rpm_var_lib_t:s0 00:09:34 INFO : set fc of /var/lib/rpm/Sigmd5 to system_u:object_r:rpm_var_lib_t:s0 00:09:34 INFO : set fc of /var/lib/rpm to system_u:object_r:rpm_var_lib_t:s0 00:09:34 INFO : set fc of /etc/lvm/archive to system_u:object_r:etc_t:s0 00:09:34 INFO : set fc of /etc/lvm/lvm.conf to system_u:object_r:etc_t:s0 00:09:34 INFO : set fc of /etc/lvm/backup to system_u:object_r:etc_t:s0 00:09:34 INFO : set fc of /etc/lvm/.cache to system_u:object_r:etc_t:s0 00:09:34 INFO : set fc of /etc/lvm to system_u:object_r:etc_t:s0 00:09:34 INFO : set fc of /dev/mapper/control to system_u:object_r:lvm_control_t:s0 00:09:34 INFO : set fc of /dev/mapper to system_u:object_r:device_t:s0 00:09:34 INFO : moving (1) to step copylogs 00:09:34 INFO : Copying anaconda logs 00:09:34 INFO : moving (1) to step dopostaction 00:09:34 INFO : moving (1) to step methodcomplete 00:09:34 INFO : moving (1) to step complete ====================================================================== dmesg | tail -11 output: sh-3.00# dmesg | tail -11 audit(1134461211.241:60): avc: denied { execmem } for pid=9343 comm="gcj-dbtool" scontext=system_u:system_r:rpm_script_t:s0 tcontext=system_u:system_r:rpm_script_t:s0 tclass=process audit(1134461235.179:61): avc: denied { write } for pid=9457 comm="useradd" name="log" dev=tmpfs ino=2967 scontext=system_u:system_r:useradd_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=sock_file audit(1134461366.707:62): avc: denied { transition } for pid=9526 comm="userhelper" name="authconfig.py" dev=sda2 ino=883014 scontext=system_u:system_r:anaconda_t:s0 tcontext=system_u:system_r:unconfined_t:s0 tclass=process audit(1134461369.655:63): avc: denied { use } for pid=9530 comm="pwconv" name="console" dev=tmpfs ino=503 scontext=system_u:system_r:sysadm_passwd_t:s0 tcontext=system_u:system_r:kernel_t:s0 tclass=fd audit(1134461369.655:64): avc: denied { read write } for pid=9530 comm="pwconv" name="console" dev=tmpfs ino=503 scontext=system_u:system_r:sysadm_passwd_t:s0 tcontext=system_u:object_r:tmpfs_t:s0 tclass=chr_file audit(1134461369.819:65): avc: denied { search } for pid=9530 comm="pwconv" name="nscd" dev=sda2 ino=1731939 scontext=system_u:system_r:sysadm_passwd_t:s0 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=dir audit(1134461370.107:66): avc: granted { setbool } for pid=9534 comm="setsebool" scontext=system_u:system_r:unconfined_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=security audit(1134461370.107:67): avc: granted { setbool } for pid=9534 comm="setsebool" scontext=system_u:system_r:unconfined_t:s0 tcontext=system_u:object_r:security_t:s0 tclass=security security: committed booleans { secure_mode:0, secure_mode_insmod:0, secure_mode_policyload:0, allow_execmem:0, allow_execmod:0, allow_execstack:0, allow_ftpd_anon_write:0, allow_gssd_read_tmp:1, allow_httpd_anon_write:0, allow_kerberos:1, allow_rsync_anon_write:0, allow_saslauthd_read_shadow:0, allow_smbd_anon_write:0, allow_ptrace:0, allow_ypbind:0, fcron_crond:0, ftp_home_dir:0, ftpd_is_daemon:1, httpd_builtin_scripting:1, httpd_can_network_connect:0, httpd_can_network_connect_db:0, httpd_can_network_relay:0, httpd_enable_cgi:1, httpd_enable_ftp_server:0, httpd_enable_homedirs:1, httpd_ssi_exec:1, httpd_tty_comm:0, httpd_unified:1, named_write_master_zones:0, nfs_export_all_rw:1, nfs_export_all_ro:1, pppd_can_insmod:0, read_default_t:1, run_ssh_inetd:0, samba_enable_home_dirs:0, spamassasin_can_network:0, squid_connect_any:0, ssh_sysadm_login:0, stunnel_is_daemon:0, use_nfs_home_dirs:0, use_samba_home_dirs:0, user_ping:1, amanda_disable_trans:0, ypbind_disable_trans:0, yppasswdd_disable_trans:0, ypserv_disable_trans:0, rshd_disable_trans:0, named_disable_trans:0, canna_disable_trans:0, uucpd_disable_trans:0, saslauthd_disable_trans:0, pegasus_disable_trans:0, crond_disable_trans:0, system_crond_disable_trans:0, nmbd_disable_trans:0, smbd_disable_trans:0, swat_disable_trans:0, winbind_disable_trans:0, howl_disable_trans:0, postgresql_disable_trans:0, snmpd_disable_trans:0, telnetd_disable_trans:0, irqbalance_disable_trans:0, mailman_mail_disable_trans:0, dbskkd_disable_trans:0, slapd_disable_trans:0, tftpd_disable_trans:0, portmap_disable_trans:0, arpwatch_disable_trans:0, dovecot_disable_trans:0, cupsd_config_disable_trans:0, cupsd_disable_trans:0, cupsd_lpd_disable_trans:0, hplip_disable_trans:0, ptal_disable_trans:0, NetworkManager_disable_trans:0, innd_disable_trans:0, comsat_disable_trans:0, squid_disable_trans:0, zebra_disable_trans:0, xfs_disable_trans:0, ktalkd_disable_trans:0, lpd_disable_trans:0, cyrus_disable_trans:0, rdisc_disable_trans:0, xdm_disable_trans:0, nscd_disable_trans:0, pppd_disable_trans:0, pptp_disable_trans:0, ftpd_disable_trans:0, gpm_disable_trans:0, postfix_disable_trans:0, fetchmail_disable_trans:0, ntpd_disable_trans:0, bluetooth_disable_trans:0, hald_disable_trans:0, avahi_disable_trans:0, gssd_disable_trans:0, rpcd_disable_trans:0, nfsd_disable_trans:0, httpd_disable_trans:0, allow_httpd_sys_script_anon_write:0, httpd_suexec_disable_trans:0, rsync_disable_trans:0, automount_disable_trans:0, kadmind_disable_trans:0, krb5kdc_disable_trans:0, dhcpd_disable_trans:0, inetd_disable_trans:0, inetd_child_disable_trans:0, mysqld_disable_trans:0, fingerd_disable_trans:0, radiusd_disable_trans:0, spamd_disable_trans:0, radvd_disable_trans:0, apmd_disable_trans:0, tcpd_disable_trans:0, stunnel_disable_trans:0, privoxy_disable_trans:0, cvs_disable_trans:0, rlogind_disable_trans:0, auditd_disable_trans:0, klogd_disable_trans:0, syslogd_disable_trans:0, dhcpc_disable_trans:0, udev_disable_trans:0, cardmgr_disable_trans:0, hotplug_disable_trans:0 } audit(1134461372.947:68): avc: denied { execmem } for pid=9577 comm="grub" scontext=system_u:system_r:anaconda_t:s0 tcontext=system_u:system_r:anaconda_t:s0 tclass=process end_request: I/O error, dev fd0, sector 0 -- Patrick Mansfield From mike at miketc.com Tue Dec 13 02:25:46 2005 From: mike at miketc.com (Mike Chambers) Date: Mon, 12 Dec 2005 20:25:46 -0600 Subject: install problem with fc devel as of dec 10 In-Reply-To: <20051213015917.GA14560@us.ibm.com> References: <20051213015917.GA14560@us.ibm.com> Message-ID: <1134440746.2384.1.camel@scrappy.miketc.com> On Mon, 2005-12-12 at 17:59 -0800, Patrick Mansfield wrote: > Has anyone been able to do a full install recently with fc devel? I did one on Saturday, or it was yesterday I can't remember. But it went smoothly for the most part. I didn't have any problems really with the install itself with anaconda. I don't know what problem your running into or at least why. Maybe it's a faulty hardware problem, or the mirror your using it's sync'd completely or something? Also remember, the system is going through rebuilds using the newer gcc so that *might* have something to do with it. -- Mike Chambers Madisonville, KY "It's better to hurt a little now, than to hurt a lot later!" From ggw at wolves.durham.nc.us Tue Dec 13 02:33:50 2005 From: ggw at wolves.durham.nc.us (G.Wolfe Woodbury) Date: Mon, 12 Dec 2005 21:33:50 -0500 Subject: install problem with fc devel as of dec 10 In-Reply-To: <20051213015917.GA14560@us.ibm.com> References: <20051213015917.GA14560@us.ibm.com> Message-ID: <20051213023350.GA9745@wolves.durham.nc.us> On Mon, Dec 12, 2005 at 05:59:17PM -0800, Patrick Mansfield wrote: > Has anyone been able to do a full install recently with fc devel? I just completed one with today's rawhide (2005-12-12) > My system is not rebooting after the rpm install step completes. Are you getting a kernel panic after the initial booting? Append "selinux=0" to the boot line and Init will start up properly. > I've searched recent bugs and found nothing ... You should also be subscribed to the fedora-test-list if you are doing rawhide installs. This has been mentioned there several times. > I've booted install kernels via both copies of the pxeboot images (copied > to my local disk) and then via CDROM. I used the boot.iso to boot fine. I had to add the selinux=0 to get the reboot to proceed properly. ..... > The main thing I notice is this dmesg output: > > audit(1134461372.947:68): avc: denied { execmem } for pid=9577 comm="grub" scontext=system_u:system_r:anaconda_t:s0 tcontext=system_u:system_r:anaconda_t:s0 tclass=process > > I would think something would have been output to the gui or serial line > if grub failed to run/install. No, selinux is interfering with the reboot because no contexts have been yet set for the system(?) > I can try installing again, installs are taking about 3 hours or so for me > (older x86 box ... no network/pxe boot), the dependency checking alone > seems to take 20 minutes or so. So, I can re-run and get more information, > but it will take some time. Try the selinux trick and see if that works. -- G.Wolfe Woodbury `- -' RHCT U The Line Eater is a boojum! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From patmans at us.ibm.com Tue Dec 13 02:41:48 2005 From: patmans at us.ibm.com (Patrick Mansfield) Date: Mon, 12 Dec 2005 18:41:48 -0800 Subject: install problem with fc devel as of dec 10 In-Reply-To: <1134440746.2384.1.camel@scrappy.miketc.com> References: <20051213015917.GA14560@us.ibm.com> <1134440746.2384.1.camel@scrappy.miketc.com> Message-ID: <20051213024148.GA15155@us.ibm.com> On Mon, Dec 12, 2005 at 08:25:46PM -0600, Mike Chambers wrote: > On Mon, 2005-12-12 at 17:59 -0800, Patrick Mansfield wrote: > > Has anyone been able to do a full install recently with fc devel? > > I did one on Saturday, or it was yesterday I can't remember. But it > went smoothly for the most part. I didn't have any problems really with > the install itself with anaconda. I don't know what problem your > running into or at least why. Maybe it's a faulty hardware problem, or > the mirror your using it's sync'd completely or something? Guess I can re-sync and try again, maybe with a different mirror. I just rebooted the install kernel once more, and ran an "upgrade existing install", that didn't take much time, but again, the reboot does not happen. But I do have a shell open on the system now ... > Also remember, the system is going through rebuilds using the newer gcc > so that *might* have something to do with it. yeh ... that could be hard to debug. I last ran OK with FC devel as of Dec 7. I had used "yum update" and not a full install to update. gcc at that time had: gcc-4.0.2-6.i386.rpm -- Patrick Mansfield From patmans at us.ibm.com Tue Dec 13 02:52:54 2005 From: patmans at us.ibm.com (Patrick Mansfield) Date: Mon, 12 Dec 2005 18:52:54 -0800 Subject: install problem with fc devel as of dec 10 In-Reply-To: <20051213023350.GA9745@wolves.durham.nc.us> References: <20051213015917.GA14560@us.ibm.com> <20051213023350.GA9745@wolves.durham.nc.us> Message-ID: <20051213025254.GB15155@us.ibm.com> On Mon, Dec 12, 2005 at 09:33:50PM -0500, G.Wolfe Woodbury wrote: > On Mon, Dec 12, 2005 at 05:59:17PM -0800, Patrick Mansfield wrote: > > Has anyone been able to do a full install recently with fc devel? > > I just completed one with today's rawhide (2005-12-12) > > > My system is not rebooting after the rpm install step completes. > > Are you getting a kernel panic after the initial booting? Yes ... > Append "selinux=0" to the boot line and Init will start up properly. I don't know if grub worked or not, I'll re-try this for the install kernel boot. > > I've searched recent bugs and found nothing ... > > You should also be subscribed to the fedora-test-list if you are doing > rawhide installs. This has been mentioned there several times. There? No wonder why I missed them :) Really: OK, but that is not what I understood from reading posts on fc-devel. I still do not understand the difference between the devel and test lists, that is development work done with FC devel implies testing. > > I've booted install kernels via both copies of the pxeboot images (copied > > to my local disk) and then via CDROM. > > I used the boot.iso to boot fine. I had to add the selinux=0 to get the > reboot to proceed properly. > > The main thing I notice is this dmesg output: > > > > audit(1134461372.947:68): avc: denied { execmem } for pid=9577 comm="grub" scontext=system_u:system_r:anaconda_t:s0 tcontext=system_u:system_r:anaconda_t:s0 tclass=process > > > > I would think something would have been output to the gui or serial line > > if grub failed to run/install. > > No, selinux is interfering with the reboot because no contexts have been > yet set for the system(?) Yes, but I'd still expect to see some sort of error message. Guess there is a bug somewhere in the installer. > > I can try installing again, installs are taking about 3 hours or so for me > > (older x86 box ... no network/pxe boot), the dependency checking alone > > seems to take 20 minutes or so. So, I can re-run and get more information, > > but it will take some time. > > Try the selinux trick and see if that works. OK thanks! -- Patrick Mansfield From philipp_subx at redfish-solutions.com Tue Dec 13 06:02:42 2005 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Mon, 12 Dec 2005 23:02:42 -0700 Subject: Installing glib2-2.6.6-1 on FC3? Message-ID: <439E6402.6080802@redfish-solutions.com> I need to be able to build gdm-2.13.0.3 on FC3 to check some features and develop a couple of fixes that I naively volunteered to do, but... it seems that gdm-2.13 requires glib2-2.6.0 or better. Can I safely install glib2-2.6.6 on FC3 (using the RPMS on atrpms.net) or will that bugger things up badly? Thanks, -Philip From ivazquez at ivazquez.net Tue Dec 13 06:59:42 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Tue, 13 Dec 2005 01:59:42 -0500 Subject: Installing glib2-2.6.6-1 on FC3? In-Reply-To: <439E6402.6080802@redfish-solutions.com> References: <439E6402.6080802@redfish-solutions.com> Message-ID: <1134457182.3672.10.camel@ignacio.lan> On Mon, 2005-12-12 at 23:02 -0700, Philip Prindeville wrote: > I need to be able to build gdm-2.13.0.3 on FC3 to check some > features and develop a couple of fixes that I naively volunteered > to do, but... it seems that gdm-2.13 requires glib2-2.6.0 or better. > > Can I safely install glib2-2.6.6 on FC3 (using the RPMS on atrpms.net) > or will that bugger things up badly? Don't be doing that. Rebuild qemu from Fedora Extras CVS instead. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 philipp_subx at redfish-solutions.com Tue Dec 13 07:59:04 2005 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Tue, 13 Dec 2005 00:59:04 -0700 Subject: Installing glib2-2.6.6-1 on FC3? In-Reply-To: <1134457182.3672.10.camel@ignacio.lan> References: <439E6402.6080802@redfish-solutions.com> <1134457182.3672.10.camel@ignacio.lan> Message-ID: <439E7F48.2040602@redfish-solutions.com> Ignacio Vazquez-Abrams wrote: >On Mon, 2005-12-12 at 23:02 -0700, Philip Prindeville wrote: > > >>I need to be able to build gdm-2.13.0.3 on FC3 to check some >>features and develop a couple of fixes that I naively volunteered >>to do, but... it seems that gdm-2.13 requires glib2-2.6.0 or better. >> >>Can I safely install glib2-2.6.6 on FC3 (using the RPMS on atrpms.net) >>or will that bugger things up badly? >> >> > >Don't be doing that. Rebuild qemu from Fedora Extras CVS instead. > > > I'm sorry... what exactly will that solve? -Philip From mpeters at mac.com Tue Dec 13 10:01:14 2005 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 13 Dec 2005 02:01:14 -0800 Subject: pango multilib Message-ID: <1134468074.2905.24.camel@locolhost.localdomain> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175510 Ignore the patch I added - it's not the right thing to do. Fedora ships two builds of pango - one for 32-bit and one for 64-bit This makes sense because 64-bit systems are likely to want both versions installed (assuming 32-bit install of Firefox, needed for 32-bit plugins, will want 32-bit pango - I don't know but that makes sense) It seems to me though that other than the pango.modules file, there is a conflict with the configuration files. It looks both 32 and 64 will want to use /etc/pango/pangorc (if it exists) and both will want to use ~/.pangorc (if it exists) and both will want to use the environmental variable PANGO_RC_FILE (if it is set) Unfortunately, those can only be correct for one or other - not both. My idea - for 64-bit builds, patch it to use /etc/pango/pangorc64 ~/.pango64 and PANGO64_RC_FILE update the pango-querymodules.1 man page for 64-bit to reflect that, and change its name to pango-querymodules-64.1 (since pango-querymodules is changed to pango-querymodules-64 already) I have a patch on my system that does that, but w/o a 64-bit system I can't test it. -=- Currently - Fedora uses an arch specific place for the pango.modules file. IE - /etc/pango/i386-redhat-linux-gnu/pango.modules I would suggest changing that back to /etc/pango/pango.modules and for the 64bit build - use /etc/pango/pango64.modules The rename of pango-querymodules to pango-querymodules-32 should be undone imho. -=- The result would be - 32-bit is like upstream intends it, with where the files are located etc. The 64-bit would have config files at /etc/pango/pango64.modules /etc/pango/pangorc64 ~/.pangorc64 /usr/bin/pango-querymodules-64 /usr/man/man1/pango-querymodules-64.1 No file conflicts, they could be installed side by side - and the current scenario where the same (optional) but incompatible config files are used by 32 and 64 would be resolved. Simplifying the pango.modules path to not have the host stuff in it would also make it easier to script rpm scriptlets that need to run pango-querymodules to regenerate the pango.modules file. -=- Thoughts on this? Are there other apps that would break by changing the pangorc name for 64-bit? I kind of doubt it because they are optional, and other apps should be getting that info from pango. -=- Where this is needed: http://mpeters.us/silgraphite/ It's a library and a set of pango modules, and they need to be seen by pango in a specific order (the pango base modules are suppose to be first in the pango ModulePath) To properly package the pango wrapper, it needs to be able to add the path to its modules to Pango's ModulesPath - and that is broken right now because the config files where that is set would set for both 32 and 64 bit pango. -=- Any other solutions would be appreciated. From buildsys at redhat.com Tue Dec 13 11:23:09 2005 From: buildsys at redhat.com (Build System) Date: Tue, 13 Dec 2005 06:23:09 -0500 Subject: rawhide report: 20051213 changes Message-ID: <200512131123.jBDBN9bX008500@porkchop.devel.redhat.com> Updated Packages: ElectricFence-2.2.2-20.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt GConf-1.0.9-17.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt GConf2-2.12.1-2.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt Guppi-0.40.3-24.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt ImageMagick-6.2.5.4-1.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt ORBit-1:0.5.17-15.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt * Wed Mar 02 2005 Mark McLoughlin 1:0.5.17-15 - Rebuild with gcc4 * Fri Aug 06 2004 Tim Waugh 1:0.5.17-14 - Fixed another m4 warning. ORBit2-2.13.2-1.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt OpenIPMI-1.4.14-14.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt PyQt-3.15-1.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt Xaw3d-1.5E-6.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt anaconda-10.90.18-1 ------------------- * Mon Dec 12 2005 Jeremy Katz - 10.90.18-1 - Handle monitor configuration in kickstart via "monitor" keyword instead of "xconfig" consistently (clumens) - Fix joe as nano (#175479) - Try to get hard drive installs working again - First steps towards using ub - Fix depcheck progress bar to actually give progress. * Sun Dec 11 2005 Peter Jones - 10.90.17-1 - Full dmraid support. (still disabled by default) ddd-3.3.11-5 ------------ * Mon Dec 12 2005 Than Ngo 3.3.11-5 - rebuilt against new openmotif-2.3 dictd-1.9.15-3 -------------- * Mon Dec 12 2005 Karsten Hopp 1.9.15-3 - rebuild with gcc-4.1 * Tue Jul 12 2005 Karsten Hopp 1.9.15-2 - Buildrequires libtool (ltdl.h) * Wed Jul 06 2005 Karsten Hopp 1.9.15-1 - update to dictd-1.9.15 - drop gcc34 patch docbook-utils-0.6.14-4.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt flex-2.5.4a-34.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gcc-4.1.0-0.7 ------------- * Mon Dec 12 2005 Jakub Jelinek 4.1.0-0.7 - update from gcc-4_1-branch (-r108157:108414) - PRs c++/19317, c++/19397, c++/19762, c++/19764, c++/25010, c++/25300, c++/25337, debug/24908, fortran/25292, libfortran/25116, libgcj/25265, target/17828, target/19005, target/23424, target/25212, target/25258, target/25311, testsuite/20772, testsuite/24478, testsuite/25167, tree-optimization/25248 - update from gomp-20050608-branch (up to -r108424) - add BuildReq for alsa-lib-devel and configure with --disable-dssi - sort files in libgcj-*.jar and touch them to latest ChangeLog timestamp, so that libgcj-*.jar is identical across multilib arches - don't use pushw instruction on i?86, as that leads to ICEs in def_cfa_1, because negative CFA offsets not multiple of 4 aren't representable in the unwind and debug info (PR debug/25023, PR target/25293) - fix ICEs with x86_64 -mlarge-data-threshold=N and STRING_CSTs (Jan Hubicka, PR target/24188) - fix Java ICE with input_filename being unset (Alexandre Oliva, #174912) - don't accept invalid int x,; in C++ (Petr Machata, PR c++/24907) - fix Java ICE in do_resolve_class (Andrew Haley, PR java/25366, PR java/25368) - make sure g*.dg/compat/struct-layout-1.exp generated tests don't use arrays with entries aligned more than their size (PR c++/25331) - don't use -liberty in g++.dg/compat/struct-layout-1.exp tests gnome-session-2.12.0-4.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-speech-0.3.9-1.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gtkhtml-1.1.9-11.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt jpackage-utils-0:1.6.3-1jpp_2rh.1 --------------------------------- * Mon Dec 12 2005 Jesse Keating 0:1.6.3-1jpp_2rh.1 - Bump release number. kdegraphics-7:3.5.0-2 --------------------- * Mon Dec 12 2005 Than Ngo 7:3.5.0-2 - apply patch to fix modula-X problem kdelibs-6:3.5.0-1.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt kdevelop-9:3.3.0-1.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt kernel-2.6.14-1.1756_FC5 ------------------------ * Mon Dec 12 2005 Dave Jones - 2.6.15-rc5-git2 * Mon Dec 12 2005 David Woodhouse - Make mambo_disk not run on real hardware; only on sim - Also make it a module - Handle iommu on DD3 boards - Fix parport patch kudzu-1.2.15-1 -------------- * Tue Dec 13 2005 Bill Nottingham - 1.2.15-1 - use ACPI EDID info if available * Fri Dec 09 2005 Bill Nottingham - 1.2.14-1 - add support for mambo virtual devices (#173307, ) * Wed Nov 16 2005 Bill Nottingham - 1.2.13-1 - integrate patch, bump version lftp-3.3.3-1.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt lha-1.14i-19.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libFS-0.99.2-2.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libart_lgpl-2.3.17-2.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libavc1394-0.5.1-1.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libbonobo-2.13.0-1.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libbonoboui-2.13.0-1.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libbtctl-0.5.0-1.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt libc-client-2002e-18.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libchewing-0.2.7-1.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libcroco-0.6.0-6.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt libdbi-0.8.1-1.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libdbi-drivers-0.8.1a-1.1 ------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libexif-0.6.12-3.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt libfontenc-0.99.2-3.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libgail-gnome-1.1.2-1.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libgcrypt-1.2.2-1.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libghttp-1:1.0.9-11.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libglade2-2.5.1-3.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libgnome-2.13.2-1.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt * Wed Nov 30 2005 Matthias Clasen - 2.13.2-1 - Update to 2.13.2 - Drop upstreamed patches * Mon Oct 24 2005 Matthias Clasen - 2.12.0.1-2 - Add schema for some new keys libgnomecanvas-2.12.0-1.1 ------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libnl-1.0-0.5.pre5.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libsemanage-1.5.1-1 ------------------- * Mon Dec 12 2005 Dan Walsh 1.5.1-1 - Upgrade to latest from NSA * Added file-mode= setting to semanage.conf, default to 0644. Changed semanage_copy_file and callers to use this mode when installing policy files to runtime locations. * Fri Dec 09 2005 Jesse Keating - rebuilt libsetrans-0.1.11-3 ------------------- * Mon Dec 12 2005 Jeremy Katz - 0.1.11-3 - there should really be a 'make dist' target that ensures that things are cleaned before a dist tarball is created. add a 'make clean' to the build just to make sure we don't get hit by this in the future libxml2-2.6.22-1.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt linuxwacom-0:0.7.0-2 -------------------- * Mon Dec 12 2005 Tim Waugh 0:0.7.0-2 - More SDK path fixes. - Don't build input driver with -fstack-protector since the X loader doesn't like it. man-pages-2.16-2 ---------------- * Tue Dec 13 2005 Ivana Varekova 2.16-2 - fix bug 174628 - mmap(2) CAN return mappings at location 0 * Fri Dec 09 2005 Jesse Keating - rebuilt * Thu Dec 08 2005 Ivana Varekova 2.16-1 - update to 2.16 mysql-5.0.16-1 -------------- * Mon Dec 12 2005 Tom Lane 5.0.16-1 - Update to MySQL 5.0.16 - Add EXCEPTIONS-CLIENT license info to the shipped documentation - Make my_config.h architecture-independent for multilib installs; put the original my_config.h into my_config_$ARCH.h - Add -fwrapv to CFLAGS so that gcc 4.1 doesn't break it * Fri Dec 09 2005 Jesse Keating - rebuilt nspr-4.6-4.1 ------------ * Fri Dec 09 2005 Jesse Keating - rebuilt nss_db-2.2-34.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt nss_ldap-244-2.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt ntp-4.2.0.a.20050816-10.1 ------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt numactl-0.6.4-1.24.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt nut-2.0.2-5.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt oaf-0.6.10-12.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt open-1.4-24.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt * Sat Mar 05 2005 Than Ngo 1.4-24 - rebuilt * Tue Feb 15 2005 Than Ngo 1.4-23 - use $RPM_OPT_FLAGS openldap-2.3.11-3.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt openobex-1.0.1-4.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt openobex-apps-1.0.0-8.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt opensm-1.0-0.4265.1.FC5.1 ------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt openssh-4.2p1-9.1.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt openssl-0.9.8a-4.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt openssl097a-0.9.7a-4.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt openswan-2.4.4-1.1.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt pam-0.80-14.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt pam_ccreds-1-8.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt pam_passwdqc-1.0.2-1.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt pam_smb-1.1.7-6.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt parted-1.6.25-5.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt passwd-0.71-2.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt patch-2.5.4-29.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt patchutils-0.2.31-2.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt * Fri Jul 22 2005 Tim Waugh - Better structure in XML documentation. pax-3.4-1.1 ----------- * Fri Dec 09 2005 Jesse Keating - rebuilt pciutils-2.1.99.test8-10.1 -------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt pcmciautils-007-1.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt pcre-6.3-1.1 ------------ * Fri Dec 09 2005 Jesse Keating - rebuilt php-5.1.1-6 ----------- * Mon Dec 12 2005 Joe Orton 5.1.1-6 - enable short_open_tag in default php.ini again (#175381) * Fri Dec 09 2005 Jesse Keating - rebuilt pilot-link-1:0.12.0-0.pre4.5.1 ------------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt pinfo-0.6.8-11.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt pkgconfig-1:0.20-2.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt planner-0.13-2.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt pnm2ppa-1:1.04-13.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt policycoreutils-1.29.1-3 ------------------------ portmap-4.0-65.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt postfix-2:2.2.5-2.1.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt postgresql-8.1.0-4.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt postgresql-odbc-08.01.0100-1.1 ------------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt ppp-2.4.3-6.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt privoxy-3.0.3-9.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt procinfo-18-18.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt procmail-3.22-16.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt procps-3.2.6-2.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt psacct-6.3.2-37.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt psmisc-21.8-1.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt pstack-1.2-7.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt psutils-1.17-25.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt pump-0.8.24-1.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt pvm-3.4.5-6.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt pyOpenSSL-0.6-1.p24.7.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt pycairo-1.0.2-1.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt pykickstart-0.11-1 ------------------ * Mon Dec 12 2005 Chris Lumens 0.11-1 - Deprecate monitor-related options to xconfig. pyorbit-2.0.1-4.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt pyparted-1.6.10-1.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt readahead-1:1.1-1.18.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt ruby-1.8.4-0.3.preview1.1 ------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt selinux-policy-2.1.4-1 ---------------------- * Mon Dec 12 2005 Dan Walsh 2.1.4-1 - Fixes for hal - Update to upstream * Mon Dec 12 2005 Dan Walsh 2.1.3-1 - Turn back on execmem since we need it for java, firefox, ooffice - Allow gpm to stream socket to itself * Mon Dec 12 2005 Jeremy Katz - 2.1.2-3 - fix requirements to be on the actual packages so that policy can get created properly at install time slang-2.0.5-5.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt star-1.5a69-1.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt * Tue Nov 08 2005 Peter Vrabec 1.5a69-1 - upgrade * Mon Oct 10 2005 Peter Vrabec 1.5a68-1 - upgrade subversion-1.2.3-6 ------------------ * Mon Dec 12 2005 Joe Orton 1.2.3-6 - fix ownership of libsvnjavahl.* (#175289) - try building javahl on ia64/ppc64 again * Fri Dec 09 2005 Jesse Keating - rebuilt system-config-kickstart-2.6.2-1 ------------------------------- * Mon Dec 12 2005 Chris Lumens 2.6.2-1 - Use monitor keyword instead of deprecated xconfig options. * Fri Dec 09 2005 Jesse Keating - rebuilt tetex-3.0-11.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt ttcp-1.12-13.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt util-linux-2.13-0.12 -------------------- * Mon Dec 12 2005 Karel Zak 2.13-0.12 - rebuilt * Fri Dec 09 2005 Jesse Keating - rebuilt vte-0.11.15-1.fc5.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt xpdf-1:3.01-6 ------------- * Mon Dec 12 2005 Than Ngo 3.01-6 - rebuilt against new openmotif-2.3 * Fri Dec 09 2005 Jesse Keating - rebuilt xterm-207-7.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt zip-2.31-1.1 ------------ * Fri Dec 09 2005 Jesse Keating - rebuilt Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 carol - 1.8.9.3-1jpp_6fc.i386 requires libgcj.so.6 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel = 0:2.6.14-1.1696_FC5 cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5smp cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 eclipse-bugzilla - 1:0.1.1_fc-5.i386 requires libgcj.so.6 eclipse-cdt - 1:3.0.1-1jpp_1fc.i386 requires libgcj.so.6 eclipse-changelog - 1:2.0.1_fc-22.i386 requires libgcj.so.6 eclipse-ecj - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-jdt - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-pde - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-platform - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-pydev - 1:0.9.3_fc-12.i386 requires libgcj.so.6 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel = 0:2.6.14-1.1696_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 gnu-crypto - 2.0.1-1jpp_8fc.i386 requires libgcj.so.6 gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.i386 requires libgcj.so.6 gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.i386 requires libgcj.so.6 jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jotm - 2.0.5-1jpp_3fc.i386 requires libgcj.so.6 jsch - 0.1.18-1jpp_2fc.i386 requires libgcj.so.6 libglade-java - 2.12.1-2.i386 requires libgcj.so.6 libgnome-java - 2.12.1-2.i386 requires libgcj.so.6 libgtk-java - 2.8.1-1.i386 requires libgcj.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.i386 requires libgcjawt.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 libvte-java - 0.11.11-6.i386 requires libgcj.so.6 lucene - 1.4.3-1jpp_7fc.i386 requires libgcj.so.6 lucene-demo - 1.4.3-1jpp_7fc.i386 requires libgcj.so.6 monolog - 1.8.6-1jpp_5fc.i386 requires libgcj.so.6 mx4j - 1:3.0.1-1jpp_5fc.i386 requires libgcj.so.6 nanoxml - 2.2.3-3jpp_3fc.i386 requires libgcj.so.6 nanoxml-lite - 2.2.3-3jpp_3fc.i386 requires libgcj.so.6 oldkilim - 1.1.3-2jpp_3fc.i386 requires libgcj.so.6 openoffice.org-core - 1:2.0.1-143.1.2.i386 requires libgcjawt.so.6 openoffice.org-core - 1:2.0.1-143.1.2.i386 requires libgcj.so.6 p6spy - 1.3-2jpp_3fc.i386 requires libgcj.so.6 regexp - 1.3-2jpp_3fc.i386 requires libgcj.so.6 struts - 1.2.4-2jpp_3fc.i386 requires libgcj.so.6 struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.i386 requires libgcj.so.6 systemtap - 0.5-2.i386 requires libdw.so.1(ELFUTILS_0.116) tomcat5 - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 tomcat5-admin-webapps - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 tomcat5-jasper - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 tomcat5-webapps - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 xalan-j2 - 2.6.0-3jpp_4fc.i386 requires libgcj.so.6 xalan-j2-demo - 2.6.0-3jpp_4fc.i386 requires libgcj.so.6 xalan-j2-xsltc - 2.6.0-3jpp_4fc.i386 requires libgcj.so.6 xerces-j2 - 2.6.2-5jpp_2fc.i386 requires libgcj.so.6 xerces-j2-demo - 2.6.2-5jpp_2fc.i386 requires libgcj.so.6 xml-commons-apis - 1.0-0.b2.7jpp_3fc.i386 requires libgcj.so.6 xml-commons-which - 1.0-0.b2.7jpp_3fc.i386 requires libgcj.so.6 Broken deps for ia64 ---------------------------------------------------------- carol - 1.8.9.3-1jpp_6fc.ia64 requires libgcj.so.6()(64bit) gnu-crypto - 2.0.1-1jpp_8fc.ia64 requires libgcj.so.6()(64bit) gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.ia64 requires libgcj.so.6()(64bit) gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.ia64 requires libgcj.so.6()(64bit) jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) jotm - 2.0.5-1jpp_3fc.ia64 requires libgcj.so.6()(64bit) jsch - 0.1.18-1jpp_2fc.ia64 requires libgcj.so.6()(64bit) libglade-java - 2.12.1-2.ia64 requires libgcj.so.6()(64bit) libgnome-java - 2.12.1-2.ia64 requires libgcj.so.6()(64bit) libgtk-java - 2.8.1-1.ia64 requires libgcj.so.6()(64bit) libvte-java - 0.11.11-6.ia64 requires libgcj.so.6()(64bit) lucene - 1.4.3-1jpp_7fc.ia64 requires libgcj.so.6()(64bit) lucene-demo - 1.4.3-1jpp_7fc.ia64 requires libgcj.so.6()(64bit) monolog - 1.8.6-1jpp_5fc.ia64 requires libgcj.so.6()(64bit) mx4j - 1:3.0.1-1jpp_5fc.ia64 requires libgcj.so.6()(64bit) nanoxml - 2.2.3-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) nanoxml-lite - 2.2.3-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) oldkilim - 1.1.3-2jpp_3fc.ia64 requires libgcj.so.6()(64bit) p6spy - 1.3-2jpp_3fc.ia64 requires libgcj.so.6()(64bit) regexp - 1.3-2jpp_3fc.ia64 requires libgcj.so.6()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs struts - 1.2.4-2jpp_3fc.ia64 requires libgcj.so.6()(64bit) struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.ia64 requires libgcj.so.6()(64bit) systemtap - 0.5-2.ia64 requires libdw.so.1(ELFUTILS_0.116)(64bit) tomcat5 - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) tomcat5-admin-webapps - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) tomcat5-jasper - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) tomcat5-webapps - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) xalan-j2 - 2.6.0-3jpp_4fc.ia64 requires libgcj.so.6()(64bit) xalan-j2-demo - 2.6.0-3jpp_4fc.ia64 requires libgcj.so.6()(64bit) xalan-j2-xsltc - 2.6.0-3jpp_4fc.ia64 requires libgcj.so.6()(64bit) xerces-j2 - 2.6.2-5jpp_2fc.ia64 requires libgcj.so.6()(64bit) xerces-j2-demo - 2.6.2-5jpp_2fc.ia64 requires libgcj.so.6()(64bit) xml-commons-apis - 1.0-0.b2.7jpp_3fc.ia64 requires libgcj.so.6()(64bit) xml-commons-which - 1.0-0.b2.7jpp_3fc.ia64 requires libgcj.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- carol - 1.8.9.3-1jpp_6fc.ppc requires libgcj.so.6 cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 eclipse-bugzilla - 1:0.1.1_fc-5.ppc requires libgcj.so.6 eclipse-cdt - 1:3.0.1-1jpp_1fc.ppc requires libgcj.so.6 eclipse-changelog - 1:2.0.1_fc-22.ppc requires libgcj.so.6 eclipse-ecj - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-jdt - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-pde - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-platform - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-pydev - 1:0.9.3_fc-12.ppc requires libgcj.so.6 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 gnu-crypto - 2.0.1-1jpp_8fc.ppc requires libgcj.so.6 gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.ppc requires libgcj.so.6 gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.ppc requires libgcj.so.6 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jotm - 2.0.5-1jpp_3fc.ppc requires libgcj.so.6 jsch - 0.1.18-1jpp_2fc.ppc requires libgcj.so.6 libglade-java - 2.12.1-2.ppc requires libgcj.so.6 libgnome-java - 2.12.1-2.ppc requires libgcj.so.6 libgtk-java - 2.8.1-1.ppc requires libgcj.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.ppc requires libgcjawt.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 libvte-java - 0.11.11-6.ppc requires libgcj.so.6 lucene - 1.4.3-1jpp_7fc.ppc requires libgcj.so.6 lucene-demo - 1.4.3-1jpp_7fc.ppc requires libgcj.so.6 monolog - 1.8.6-1jpp_5fc.ppc requires libgcj.so.6 mx4j - 1:3.0.1-1jpp_5fc.ppc requires libgcj.so.6 nanoxml - 2.2.3-3jpp_3fc.ppc requires libgcj.so.6 nanoxml-lite - 2.2.3-3jpp_3fc.ppc requires libgcj.so.6 oldkilim - 1.1.3-2jpp_3fc.ppc requires libgcj.so.6 openoffice.org-core - 1:2.0.1-143.1.2.ppc requires libgcjawt.so.6 openoffice.org-core - 1:2.0.1-143.1.2.ppc requires libgcj.so.6 p6spy - 1.3-2jpp_3fc.ppc requires libgcj.so.6 regexp - 1.3-2jpp_3fc.ppc requires libgcj.so.6 struts - 1.2.4-2jpp_3fc.ppc requires libgcj.so.6 struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.ppc requires libgcj.so.6 systemtap - 0.5-2.ppc requires libdw.so.1(ELFUTILS_0.116) tomcat5 - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 tomcat5-admin-webapps - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 tomcat5-jasper - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 tomcat5-webapps - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 xalan-j2 - 2.6.0-3jpp_4fc.ppc requires libgcj.so.6 xalan-j2-demo - 2.6.0-3jpp_4fc.ppc requires libgcj.so.6 xalan-j2-xsltc - 2.6.0-3jpp_4fc.ppc requires libgcj.so.6 xerces-j2 - 2.6.2-5jpp_2fc.ppc requires libgcj.so.6 xerces-j2-demo - 2.6.2-5jpp_2fc.ppc requires libgcj.so.6 xml-commons-apis - 1.0-0.b2.7jpp_3fc.ppc requires libgcj.so.6 xml-commons-which - 1.0-0.b2.7jpp_3fc.ppc requires libgcj.so.6 Broken deps for ppc64 ---------------------------------------------------------- carol - 1.8.9.3-1jpp_6fc.ppc64 requires libgcj.so.6()(64bit) cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 gnu-crypto - 2.0.1-1jpp_8fc.ppc64 requires libgcj.so.6()(64bit) gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.ppc64 requires libgcj.so.6()(64bit) gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.ppc64 requires libgcj.so.6()(64bit) jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) jotm - 2.0.5-1jpp_3fc.ppc64 requires libgcj.so.6()(64bit) jsch - 0.1.18-1jpp_2fc.ppc64 requires libgcj.so.6()(64bit) libglade-java - 2.12.1-2.ppc64 requires libgcj.so.6()(64bit) libgnome-java - 2.12.1-2.ppc64 requires libgcj.so.6()(64bit) libgtk-java - 2.8.1-1.ppc64 requires libgcj.so.6()(64bit) libvte-java - 0.11.11-6.ppc64 requires libgcj.so.6()(64bit) lucene - 1.4.3-1jpp_7fc.ppc64 requires libgcj.so.6()(64bit) lucene-demo - 1.4.3-1jpp_7fc.ppc64 requires libgcj.so.6()(64bit) monolog - 1.8.6-1jpp_5fc.ppc64 requires libgcj.so.6()(64bit) mx4j - 1:3.0.1-1jpp_5fc.ppc64 requires libgcj.so.6()(64bit) nanoxml - 2.2.3-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) nanoxml-lite - 2.2.3-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) oldkilim - 1.1.3-2jpp_3fc.ppc64 requires libgcj.so.6()(64bit) p6spy - 1.3-2jpp_3fc.ppc64 requires libgcj.so.6()(64bit) regexp - 1.3-2jpp_3fc.ppc64 requires libgcj.so.6()(64bit) struts - 1.2.4-2jpp_3fc.ppc64 requires libgcj.so.6()(64bit) struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.ppc64 requires libgcj.so.6()(64bit) tomcat5 - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) tomcat5-admin-webapps - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) tomcat5-jasper - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) tomcat5-webapps - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) xalan-j2 - 2.6.0-3jpp_4fc.ppc64 requires libgcj.so.6()(64bit) xalan-j2-demo - 2.6.0-3jpp_4fc.ppc64 requires libgcj.so.6()(64bit) xalan-j2-xsltc - 2.6.0-3jpp_4fc.ppc64 requires libgcj.so.6()(64bit) xerces-j2 - 2.6.2-5jpp_2fc.ppc64 requires libgcj.so.6()(64bit) xerces-j2-demo - 2.6.2-5jpp_2fc.ppc64 requires libgcj.so.6()(64bit) xml-commons-apis - 1.0-0.b2.7jpp_3fc.ppc64 requires libgcj.so.6()(64bit) xml-commons-which - 1.0-0.b2.7jpp_3fc.ppc64 requires libgcj.so.6()(64bit) Broken deps for s390 ---------------------------------------------------------- carol - 1.8.9.3-1jpp_6fc.s390 requires libgcj.so.6 gnu-crypto - 2.0.1-1jpp_8fc.s390 requires libgcj.so.6 gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.s390 requires libgcj.so.6 gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.s390 requires libgcj.so.6 jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jotm - 2.0.5-1jpp_3fc.s390 requires libgcj.so.6 jsch - 0.1.18-1jpp_2fc.s390 requires libgcj.so.6 libglade-java - 2.12.1-2.s390 requires libgcj.so.6 libgnome-java - 2.12.1-2.s390 requires libgcj.so.6 libgtk-java - 2.8.1-1.s390 requires libgcj.so.6 libvte-java - 0.11.11-6.s390 requires libgcj.so.6 lucene - 1.4.3-1jpp_7fc.s390 requires libgcj.so.6 lucene-demo - 1.4.3-1jpp_7fc.s390 requires libgcj.so.6 monolog - 1.8.6-1jpp_5fc.s390 requires libgcj.so.6 mx4j - 1:3.0.1-1jpp_5fc.s390 requires libgcj.so.6 nanoxml - 2.2.3-3jpp_3fc.s390 requires libgcj.so.6 nanoxml-lite - 2.2.3-3jpp_3fc.s390 requires libgcj.so.6 oldkilim - 1.1.3-2jpp_3fc.s390 requires libgcj.so.6 p6spy - 1.3-2jpp_3fc.s390 requires libgcj.so.6 regexp - 1.3-2jpp_3fc.s390 requires libgcj.so.6 struts - 1.2.4-2jpp_3fc.s390 requires libgcj.so.6 struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.s390 requires libgcj.so.6 tomcat5 - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 tomcat5-admin-webapps - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 tomcat5-jasper - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 tomcat5-webapps - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 xalan-j2 - 2.6.0-3jpp_4fc.s390 requires libgcj.so.6 xalan-j2-demo - 2.6.0-3jpp_4fc.s390 requires libgcj.so.6 xalan-j2-xsltc - 2.6.0-3jpp_4fc.s390 requires libgcj.so.6 xerces-j2 - 2.6.2-5jpp_2fc.s390 requires libgcj.so.6 xerces-j2-demo - 2.6.2-5jpp_2fc.s390 requires libgcj.so.6 xml-commons-apis - 1.0-0.b2.7jpp_3fc.s390 requires libgcj.so.6 xml-commons-which - 1.0-0.b2.7jpp_3fc.s390 requires libgcj.so.6 Broken deps for s390x ---------------------------------------------------------- carol - 1.8.9.3-1jpp_6fc.s390x requires libgcj.so.6()(64bit) gnu-crypto - 2.0.1-1jpp_8fc.s390x requires libgcj.so.6()(64bit) gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.s390x requires libgcj.so.6()(64bit) gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.s390x requires libgcj.so.6()(64bit) jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) jotm - 2.0.5-1jpp_3fc.s390x requires libgcj.so.6()(64bit) jsch - 0.1.18-1jpp_2fc.s390x requires libgcj.so.6()(64bit) libgconf-java - 2.12.0-2.s390x requires libgcj.so.6()(64bit) libgconf-java - 2.12.0-2.s390x requires libglibjava-0.2.so()(64bit) libgconf-java - 2.12.0-2.s390x requires libglibjni-0.2.so()(64bit) libgconf-java - 2.12.0-2.s390x requires libcairojava-1.0.so()(64bit) libglade-java - 2.12.0-5.s390x requires libgcj.so.6()(64bit) libglade-java - 2.12.0-5.s390x requires libglibjava-0.2.so()(64bit) libglade-java - 2.12.0-5.s390x requires libglibjni-0.2.so()(64bit) libglade-java - 2.12.0-5.s390x requires libcairojava-1.0.so()(64bit) libgnome-java - 2.12.0-2.s390x requires libgcj.so.6()(64bit) libgnome-java - 2.12.0-2.s390x requires libglibjava-0.2.so()(64bit) libgnome-java - 2.12.0-2.s390x requires libglibjni-0.2.so()(64bit) libgnome-java - 2.12.0-2.s390x requires libcairojava-1.0.so()(64bit) libgtk-java - 2.8.0-7.s390x requires libgcj.so.6()(64bit) libgtk-java - 2.8.0-7.s390x requires libglibjava-0.2.so()(64bit) libgtk-java - 2.8.0-7.s390x requires libglibjni-0.2.so()(64bit) libvte-java - 0.11.11-6.s390x requires libgcj.so.6()(64bit) libvte-java - 0.11.11-6.s390x requires libglibjava-0.2.so()(64bit) libvte-java - 0.11.11-6.s390x requires libglibjni-0.2.so()(64bit) libvte-java - 0.11.11-6.s390x requires libcairojava-1.0.so()(64bit) lucene - 1.4.3-1jpp_7fc.s390x requires libgcj.so.6()(64bit) lucene-demo - 1.4.3-1jpp_7fc.s390x requires libgcj.so.6()(64bit) monolog - 1.8.6-1jpp_5fc.s390x requires libgcj.so.6()(64bit) mx4j - 1:3.0.1-1jpp_5fc.s390x requires libgcj.so.6()(64bit) nanoxml - 2.2.3-3jpp_3fc.s390x requires libgcj.so.6()(64bit) nanoxml-lite - 2.2.3-3jpp_3fc.s390x requires libgcj.so.6()(64bit) oldkilim - 1.1.3-2jpp_3fc.s390x requires libgcj.so.6()(64bit) p6spy - 1.3-2jpp_3fc.s390x requires libgcj.so.6()(64bit) regexp - 1.3-2jpp_3fc.s390x requires libgcj.so.6()(64bit) struts - 1.2.4-2jpp_3fc.s390x requires libgcj.so.6()(64bit) struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.s390x requires libgcj.so.6()(64bit) tomcat5 - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) tomcat5-admin-webapps - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) tomcat5-jasper - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) tomcat5-webapps - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) xalan-j2 - 2.6.0-3jpp_4fc.s390x requires libgcj.so.6()(64bit) xalan-j2-demo - 2.6.0-3jpp_4fc.s390x requires libgcj.so.6()(64bit) xalan-j2-xsltc - 2.6.0-3jpp_4fc.s390x requires libgcj.so.6()(64bit) xerces-j2 - 2.6.2-5jpp_2fc.s390x requires libgcj.so.6()(64bit) xerces-j2-demo - 2.6.2-5jpp_2fc.s390x requires libgcj.so.6()(64bit) xml-commons-apis - 1.0-0.b2.7jpp_3fc.s390x requires libgcj.so.6()(64bit) xml-commons-which - 1.0-0.b2.7jpp_3fc.s390x requires libgcj.so.6()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 carol - 1.8.9.3-1jpp_6fc.x86_64 requires libgcj.so.6()(64bit) cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 eclipse-bugzilla - 1:0.1.1_fc-5.x86_64 requires libgcj.so.6()(64bit) eclipse-cdt - 1:3.0.1-1jpp_1fc.x86_64 requires libgcj.so.6()(64bit) eclipse-changelog - 1:2.0.1_fc-22.x86_64 requires libgcj.so.6()(64bit) eclipse-ecj - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-jdt - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-pde - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-platform - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-pydev - 1:0.9.3_fc-12.x86_64 requires libgcj.so.6()(64bit) gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 gnu-crypto - 2.0.1-1jpp_8fc.x86_64 requires libgcj.so.6()(64bit) gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.x86_64 requires libgcj.so.6()(64bit) gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.x86_64 requires libgcj.so.6()(64bit) jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jotm - 2.0.5-1jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jsch - 0.1.18-1jpp_2fc.x86_64 requires libgcj.so.6()(64bit) libglade-java - 2.12.1-2.x86_64 requires libgcj.so.6()(64bit) libgnome-java - 2.12.1-2.x86_64 requires libgcj.so.6()(64bit) libgtk-java - 2.8.1-1.x86_64 requires libgcj.so.6()(64bit) libswt3-gtk2 - 1:3.1.1-1jpp_9fc.x86_64 requires libgcjawt.so.6()(64bit) libswt3-gtk2 - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) libvte-java - 0.11.11-6.x86_64 requires libgcj.so.6()(64bit) lucene - 1.4.3-1jpp_7fc.x86_64 requires libgcj.so.6()(64bit) lucene-demo - 1.4.3-1jpp_7fc.x86_64 requires libgcj.so.6()(64bit) monolog - 1.8.6-1jpp_5fc.x86_64 requires libgcj.so.6()(64bit) mx4j - 1:3.0.1-1jpp_5fc.x86_64 requires libgcj.so.6()(64bit) nanoxml - 2.2.3-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) nanoxml-lite - 2.2.3-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) oldkilim - 1.1.3-2jpp_3fc.x86_64 requires libgcj.so.6()(64bit) openoffice.org-core - 1:2.0.1-143.1.2.i386 requires libgcjawt.so.6 openoffice.org-core - 1:2.0.1-143.1.2.i386 requires libgcj.so.6 p6spy - 1.3-2jpp_3fc.x86_64 requires libgcj.so.6()(64bit) regexp - 1.3-2jpp_3fc.x86_64 requires libgcj.so.6()(64bit) struts - 1.2.4-2jpp_3fc.x86_64 requires libgcj.so.6()(64bit) struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.x86_64 requires libgcj.so.6()(64bit) systemtap - 0.5-2.x86_64 requires libdw.so.1(ELFUTILS_0.116)(64bit) tomcat5 - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) tomcat5-admin-webapps - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) tomcat5-jasper - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) tomcat5-webapps - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) xalan-j2 - 2.6.0-3jpp_4fc.x86_64 requires libgcj.so.6()(64bit) xalan-j2-demo - 2.6.0-3jpp_4fc.x86_64 requires libgcj.so.6()(64bit) xalan-j2-xsltc - 2.6.0-3jpp_4fc.x86_64 requires libgcj.so.6()(64bit) xerces-j2 - 2.6.2-5jpp_2fc.x86_64 requires libgcj.so.6()(64bit) xerces-j2-demo - 2.6.2-5jpp_2fc.x86_64 requires libgcj.so.6()(64bit) xml-commons-apis - 1.0-0.b2.7jpp_3fc.x86_64 requires libgcj.so.6()(64bit) xml-commons-which - 1.0-0.b2.7jpp_3fc.x86_64 requires libgcj.so.6()(64bit) From Axel.Thimm at ATrpms.net Tue Dec 13 11:42:31 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Tue, 13 Dec 2005 12:42:31 +0100 Subject: Installing glib2-2.6.6-1 on FC3? In-Reply-To: <439E6402.6080802@redfish-solutions.com> References: <439E6402.6080802@redfish-solutions.com> Message-ID: <20051213114231.GC24704@neu.nirvana> On Mon, Dec 12, 2005 at 11:02:42PM -0700, Philip Prindeville wrote: > I need to be able to build gdm-2.13.0.3 on FC3 to check some > features and develop a couple of fixes that I naively volunteered > to do, but... it seems that gdm-2.13 requires glib2-2.6.0 or better. > > Can I safely install glib2-2.6.6 on FC3 (using the RPMS on atrpms.net) > or will that bugger things up badly? I would have to admit to be biased. It was promoted to the stable section of ATrpms some ages ago after QAing it in bleeding and testing repos, and several thousand of users are productively using it. And even if you don't take my word: The nice thing about packages is that they can be cast back to their previous version. :) -- 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 veillard at redhat.com Tue Dec 13 13:14:57 2005 From: veillard at redhat.com (Daniel Veillard) Date: Tue, 13 Dec 2005 08:14:57 -0500 Subject: New mailing list dedicated to Xen support in Fedora Message-ID: <20051213131457.GM4116@redhat.com> Hello, Xen support was added in Fedora Core 4, but except for the Fedora Wiki pages to set-up and use Xen in this environment [1] [2], there wasn't a clear place to report and discuss issues specific to Xen, especially as our FC4 packages are now a bit aged and as the new support in rawhide is still in development. To this intent and to help the new development being done toward Fedora Core 5 integration of Xen, there is a new mailing-list available, the description and subscription informations are at: https://www.redhat.com/mailman/listinfo/fedora-xen The public archive will be at https://www.redhat.com/archives/fedora-xen/ thanks for your attention, Daniel [1] http://fedoraproject.org/wiki/Tools/xen [2] http://fedoraproject.org/wiki/FedoraXenQuickstart -- Daniel Veillard | Red Hat http://redhat.com/ veillard at redhat.com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/ http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/ From kmaraas at broadpark.no Tue Dec 13 13:21:56 2005 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Tue, 13 Dec 2005 14:21:56 +0100 Subject: rawhide report: 20051213 changes In-Reply-To: <200512131123.jBDBN9bX008500@porkchop.devel.redhat.com> References: <200512131123.jBDBN9bX008500@porkchop.devel.redhat.com> Message-ID: <1134480117.2791.3.camel@localhost.localdomain> tir, 13,.12.2005 kl. 06.23 -0500, skrev Build System: > > Broken deps for i386 > ---------------------------------------------------------- > openoffice.org-core - 1:2.0.1-143.1.2.i386 requires libgcjawt.so.6 > openoffice.org-core - 1:2.0.1-143.1.2.i386 requires libgcj.so.6 Does anyone know how long until updates of these packages will hit rawhide? I guess I can uninstall all the java/tomcat/eclipse stuff for now, but openoffice would be nice to have at work :-) /me is anxious to test the new gcc... Cheers Kjartan From ilpettegolo at yahoo.it Tue Dec 13 13:26:16 2005 From: ilpettegolo at yahoo.it (Mario Pascucci) Date: Tue, 13 Dec 2005 14:26:16 +0100 Subject: rhn-applet replacement... Message-ID: <1134480376.8843.9.camel@defiant> I've installed Fedora Core 4, and I found that rhn-applet alert icon is not working at all. Playing with bash scripting, I've made a very simple script that checks via "sudoed" command 'yum check-update' for updates and display an icon on the Gnome panel "notification area" applet using Zenity. It's a very poor method, but it works... If someone is interested, I'm happy to share this very simple script. HTH -- Mario 'Reliant' Pascucci http://ilpettegolo.altervista.org/ ___________________________________ Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB http://mail.yahoo.it From caolanm at redhat.com Tue Dec 13 13:31:41 2005 From: caolanm at redhat.com (Caolan McNamara) Date: Tue, 13 Dec 2005 13:31:41 +0000 Subject: rawhide report: 20051213 changes In-Reply-To: <1134480117.2791.3.camel@localhost.localdomain> References: <200512131123.jBDBN9bX008500@porkchop.devel.redhat.com> <1134480117.2791.3.camel@localhost.localdomain> Message-ID: <1134480701.22912.13.camel@localhost.localdomain> On Tue, 2005-12-13 at 14:21 +0100, Kjartan Maraas wrote: > tir, 13,.12.2005 kl. 06.23 -0500, skrev Build System: > > > > > Broken deps for i386 > > ---------------------------------------------------------- > > openoffice.org-core - 1:2.0.1-143.1.2.i386 requires libgcjawt.so.6 > > openoffice.org-core - 1:2.0.1-143.1.2.i386 requires libgcj.so.6 > > Does anyone know how long until updates of these packages will hit > rawhide? I guess I can uninstall all the java/tomcat/eclipse stuff for > now, but openoffice would be nice to have at work :-) Figured out the problem stalling the rebuild now, (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25389), and am building it + workaround now, so tomorrow if all goes well. C. From kmaraas at broadpark.no Tue Dec 13 13:58:25 2005 From: kmaraas at broadpark.no (Kjartan Maraas) Date: Tue, 13 Dec 2005 14:58:25 +0100 Subject: rawhide report: 20051213 changes In-Reply-To: <1134480701.22912.13.camel@localhost.localdomain> References: <200512131123.jBDBN9bX008500@porkchop.devel.redhat.com> <1134480117.2791.3.camel@localhost.localdomain> <1134480701.22912.13.camel@localhost.localdomain> Message-ID: <1134482306.2628.0.camel@localhost.localdomain> tir, 13,.12.2005 kl. 13.31 +0000, skrev Caolan McNamara: > On Tue, 2005-12-13 at 14:21 +0100, Kjartan Maraas wrote: > > tir, 13,.12.2005 kl. 06.23 -0500, skrev Build System: > > > > > > > > Broken deps for i386 > > > ---------------------------------------------------------- > > > openoffice.org-core - 1:2.0.1-143.1.2.i386 requires libgcjawt.so.6 > > > openoffice.org-core - 1:2.0.1-143.1.2.i386 requires libgcj.so.6 > > > > Does anyone know how long until updates of these packages will hit > > rawhide? I guess I can uninstall all the java/tomcat/eclipse stuff for > > now, but openoffice would be nice to have at work :-) > > Figured out the problem stalling the rebuild now, > (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25389), and am building it > + workaround now, so tomorrow if all goes well. > Looking forward to it. Thanks Kjartan From bmillett at gmail.com Tue Dec 13 14:12:02 2005 From: bmillett at gmail.com (Brian Millett) Date: Tue, 13 Dec 2005 08:12:02 -0600 Subject: rawhide report: 20051213 changes In-Reply-To: <200512131123.jBDBN9bX008500@porkchop.devel.redhat.com> References: <200512131123.jBDBN9bX008500@porkchop.devel.redhat.com> Message-ID: <1134483123.3831.11.camel@localhost.localdomain> On Tue, 2005-12-13 at 06:23 -0500, Build System wrote: > pcmciautils-007-1.1 > ------------------- > * Fri Dec 09 2005 Jesse Keating > - rebuilt > Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package pcmciautils.i386 0:007-1.1 set to be updated --> Running transaction check --> Processing Conflict: hwdata conflicts pcmcia-cs --> Finished Dependency Resolution Error: hwdata conflicts with pcmcia-cs Ok, I don't see this as a conflict in the report, am I confused? Thanks. -- Brian Millett - [ Ivanova, "The Geometry of Shadows"] "If it gets too bad I'll just gnaw it off at the ankle." From dakingun at gmail.com Tue Dec 13 14:31:14 2005 From: dakingun at gmail.com (Deji Akingunola) Date: Tue, 13 Dec 2005 09:31:14 -0500 Subject: rawhide report: 20051213 changes In-Reply-To: <1134483123.3831.11.camel@localhost.localdomain> References: <200512131123.jBDBN9bX008500@porkchop.devel.redhat.com> <1134483123.3831.11.camel@localhost.localdomain> Message-ID: On 12/13/05, Brian Millett wrote: > On Tue, 2005-12-13 at 06:23 -0500, Build System wrote: > > > pcmciautils-007-1.1 > > ------------------- > > * Fri Dec 09 2005 Jesse Keating > > - rebuilt > > > Resolving Dependencies > --> Populating transaction set with selected packages. Please wait. > ---> Package pcmciautils.i386 0:007-1.1 set to be updated > --> Running transaction check > --> Processing Conflict: hwdata conflicts pcmcia-cs > --> Finished Dependency Resolution > Error: hwdata conflicts with pcmcia-cs > > Ok, I don't see this as a conflict in the report, am I confused? > pcmcia-cs is no longer in the tree, it has been obsoleted by pcmciautils. Remove it and continue with the update. Deji From bgerst at didntduck.org Tue Dec 13 14:46:53 2005 From: bgerst at didntduck.org (Brian Gerst) Date: Tue, 13 Dec 2005 09:46:53 -0500 Subject: rawhide report: 20051213 changes In-Reply-To: References: <200512131123.jBDBN9bX008500@porkchop.devel.redhat.com> <1134483123.3831.11.camel@localhost.localdomain> Message-ID: <439EDEDD.10401@didntduck.org> Deji Akingunola wrote: > On 12/13/05, Brian Millett wrote: > >>On Tue, 2005-12-13 at 06:23 -0500, Build System wrote: >> >> >>>pcmciautils-007-1.1 >>>------------------- >>>* Fri Dec 09 2005 Jesse Keating >>>- rebuilt >>> >> >>Resolving Dependencies >>--> Populating transaction set with selected packages. Please wait. >>---> Package pcmciautils.i386 0:007-1.1 set to be updated >>--> Running transaction check >>--> Processing Conflict: hwdata conflicts pcmcia-cs >>--> Finished Dependency Resolution >>Error: hwdata conflicts with pcmcia-cs >> >>Ok, I don't see this as a conflict in the report, am I confused? >> > > pcmcia-cs is no longer in the tree, it has been obsoleted by > pcmciautils. Remove it and continue with the update. > > Deji > I get the same error: Error: hwdata conflicts with pcmcia-cs # rpm -q pcmcia-cs package pcmcia-cs is not installed # rpm -q --whatprovides pcmcia-cs no package provides pcmcia-cs # rpm -qa|grep pcmcia pcmciautils-007-1 I have no idea why yum thinks pcmcia-cs is still installed. -- Brian Gerst From bmillett at gmail.com Tue Dec 13 14:45:08 2005 From: bmillett at gmail.com (Brian Millett) Date: Tue, 13 Dec 2005 08:45:08 -0600 Subject: rawhide report: 20051213 changes In-Reply-To: References: <200512131123.jBDBN9bX008500@porkchop.devel.redhat.com> <1134483123.3831.11.camel@localhost.localdomain> Message-ID: <1134485108.3831.17.camel@localhost.localdomain> On Tue, 2005-12-13 at 09:31 -0500, Deji Akingunola wrote: > On 12/13/05, Brian Millett wrote: > > On Tue, 2005-12-13 at 06:23 -0500, Build System wrote: > > > > > pcmciautils-007-1.1 > > > ------------------- > > > * Fri Dec 09 2005 Jesse Keating > > > - rebuilt > > > > > Resolving Dependencies > > --> Populating transaction set with selected packages. Please wait. > > ---> Package pcmciautils.i386 0:007-1.1 set to be updated > > --> Running transaction check > > --> Processing Conflict: hwdata conflicts pcmcia-cs > > --> Finished Dependency Resolution > > Error: hwdata conflicts with pcmcia-cs > > > > Ok, I don't see this as a conflict in the report, am I confused? > > > pcmcia-cs is no longer in the tree, it has been obsoleted by > pcmciautils. Remove it and continue with the update. Thats the question. [bpm]$ rpm -qa | egrep "hwdata|pcmcia" hwdata-0.172-1.1 pcmciautils-007-1 I do not have it installed. pcmciautils or hwdata must think it is there, or something. -- Brian Millett - [ Garibaldi, "The Gathering"] "Commander, this little breach of security isn't going to affect my Christmas bonus, is it?" From jspaleta at gmail.com Tue Dec 13 14:51:04 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 13 Dec 2005 09:51:04 -0500 Subject: rawhide report: 20051213 changes In-Reply-To: <1134483123.3831.11.camel@localhost.localdomain> References: <200512131123.jBDBN9bX008500@porkchop.devel.redhat.com> <1134483123.3831.11.camel@localhost.localdomain> Message-ID: <604aa7910512130651x404adf29lf48c60e8853b5845@mail.gmail.com> On 12/13/05, Brian Millett wrote: > Ok, I don't see this as a conflict in the report, am I confused? You are very confused. pcmcia-cs was removed from the rawhide tree months ago and the explicit conflict added to hwdata. hwdata's changelog: * Wed Jul 13 2005 Bill Nottingham - 0.162-1 - remove /etc/pcmcia/config, conflict with pcmcia-cs > rpm -q hwdata hwdata-0.172-1 > rpm -q --conflicts hwdata Xconfigurator system-config-display < 1.0.31 pcmcia-cs <------------------------Explicit conflict that you see reported kudzu < 1.2.0 If you are just seeing this problem now, you haven't updated hwdata from rawhide in a long long while. And if that's the case, you've probably not updated several other packages in a long while either and you might see several other problems associated with moving from an aged install state to rawhide that the daily reports have no knowledge of. -jef"doom-monger"spaleta From jspaleta at gmail.com Tue Dec 13 14:52:56 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 13 Dec 2005 09:52:56 -0500 Subject: rawhide report: 20051213 changes In-Reply-To: <1134485108.3831.17.camel@localhost.localdomain> References: <200512131123.jBDBN9bX008500@porkchop.devel.redhat.com> <1134483123.3831.11.camel@localhost.localdomain> <1134485108.3831.17.camel@localhost.localdomain> Message-ID: <604aa7910512130652y61b6db08p95d86f5e6d4dba6a@mail.gmail.com> On 12/13/05, Brian Millett wrote: > [bpm]$ rpm -qa | egrep "hwdata|pcmcia" > hwdata-0.172-1.1 > pcmciautils-007-1 rpm -q --provides pcmciautils rpm -q --obsoletes pcmciautils -jef"If only repoquery worked on rawhide at the moment...I'd not have to ask.."spaleta From jspaleta at gmail.com Tue Dec 13 15:32:33 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 13 Dec 2005 10:32:33 -0500 Subject: rawhide report: 20051213 changes In-Reply-To: <604aa7910512130651x404adf29lf48c60e8853b5845@mail.gmail.com> References: <200512131123.jBDBN9bX008500@porkchop.devel.redhat.com> <1134483123.3831.11.camel@localhost.localdomain> <604aa7910512130651x404adf29lf48c60e8853b5845@mail.gmail.com> Message-ID: <604aa7910512130732l2cb60f57qee0e1e93535a2f09@mail.gmail.com> On 12/13/05, Jeff Spaleta wrote: > On 12/13/05, Brian Millett wrote: > > Ok, I don't see this as a conflict in the report, am I confused? > > You are very confused. I take this back.... after running repoquery from an fc4 box against the rawhide tree. Its clear there is a problem. repoquery --repoid=development -q --provides pcmciautils config(pcmciautils) = 007-1.1 pcmcia-cs <------------------- THIS IS THE PROBLEM pcmciautils = 007-1.1 package pcmcia-cs-007.1 did not provide pcmcia-cs package pcmcia-cs-007.1.1 does hwdata has an explicit conflict on pcmcia-cs and thus....doom. So either hwdata needs to have its conflict removed or pcimciautils has to have its provide removed either way i expect the issue to be resolved in another package rebuild, hopefully by tomorrow. -jef From bmillett at gmail.com Tue Dec 13 15:37:26 2005 From: bmillett at gmail.com (Brian Millett) Date: Tue, 13 Dec 2005 09:37:26 -0600 Subject: rawhide report: 20051213 changes In-Reply-To: <604aa7910512130732l2cb60f57qee0e1e93535a2f09@mail.gmail.com> References: <200512131123.jBDBN9bX008500@porkchop.devel.redhat.com> <1134483123.3831.11.camel@localhost.localdomain> <604aa7910512130651x404adf29lf48c60e8853b5845@mail.gmail.com> <604aa7910512130732l2cb60f57qee0e1e93535a2f09@mail.gmail.com> Message-ID: <1134488246.3831.21.camel@localhost.localdomain> On Tue, 2005-12-13 at 10:32 -0500, Jeff Spaleta wrote: > On 12/13/05, Jeff Spaleta wrote: > > On 12/13/05, Brian Millett wrote: > > > Ok, I don't see this as a conflict in the report, am I confused? > > > > You are very confused. > I take this back.... after running repoquery from an fc4 box against > the rawhide tree. Its clear there is a problem. > > repoquery --repoid=development -q --provides pcmciautils > config(pcmciautils) = 007-1.1 > pcmcia-cs <------------------- THIS IS THE PROBLEM > pcmciautils = 007-1.1 > > package pcmcia-cs-007.1 did not provide pcmcia-cs > package pcmcia-cs-007.1.1 does > hwdata has an explicit conflict on pcmcia-cs and thus....doom. > > So either hwdata needs to have its conflict removed > or pcimciautils has to have its provide removed > either way i expect the issue to be resolved in another package > rebuild, hopefully by tomorrow. Very cool. I'll admit that I've not really looked at using repoquery. Great tool. Also good tutorial/example of how it works. Thanks Jef. -- Brian Millett - [ G'Kar, "The Parliament of Dreams"] "Earthers have a phrase: Keep your friends close and your enemies closer. I think they stole it from us." From katzj at redhat.com Tue Dec 13 16:13:53 2005 From: katzj at redhat.com (Jeremy Katz) Date: Tue, 13 Dec 2005 11:13:53 -0500 Subject: install problem with fc devel as of dec 10 In-Reply-To: <20051213023350.GA9745@wolves.durham.nc.us> References: <20051213015917.GA14560@us.ibm.com> <20051213023350.GA9745@wolves.durham.nc.us> Message-ID: <1134490433.23818.6.camel@bree.local.net> On Mon, 2005-12-12 at 21:33 -0500, G.Wolfe Woodbury wrote: > On Mon, Dec 12, 2005 at 05:59:17PM -0800, Patrick Mansfield wrote: > ..... > > > The main thing I notice is this dmesg output: > > > > audit(1134461372.947:68): avc: denied { execmem } for pid=9577 comm="grub" scontext=system_u:system_r:anaconda_t:s0 tcontext=system_u:system_r:anaconda_t:s0 tclass=process > > > > I would think something would have been output to the gui or serial line > > if grub failed to run/install. Remember, anaconda runs in permissive mode. So any "denials" are just "this would have been denied", not "this was denied". Mostly because we're in a very strange environment and things would blow up horribly otherwise ;) But we have to have policy somewhat loaded as otherwise, the file contexts aren't known to the kernel for setting the xattrs. > No, selinux is interfering with the reboot because no contexts have been > yet set for the system(?) selinux=0 is needed because the policy package didn't have correct requirements on things it ran in its scripts. I've hopefully got that fixed up today, but Chris saw something else weird when he tried an install a little bit ago. So we'll be taking a look at that. Jeremy From harald at redhat.com Tue Dec 13 16:44:32 2005 From: harald at redhat.com (Harald Hoyer) Date: Tue, 13 Dec 2005 17:44:32 +0100 Subject: udev alpha testing In-Reply-To: <6f6293f10511291124v44f27863p8e5cca2a4973d2a6@mail.gmail.com> References: <438C656B.2080701@redhat.com> <6f6293f10511291124v44f27863p8e5cca2a4973d2a6@mail.gmail.com> Message-ID: <439EFA70.2010400@redhat.com> Felipe Alfaro Solana wrote: >>I would be glad, if the really brave could compile, install and test: >>ftp://people.redhat.com/harald/udev/076-1/ >> >>Beware this could end in a non-bootable system. >> >>This version removes the hardware initializing/module loading phase from rc.sysinit. Udev should do most, if >>not all job. I am interested in any missing modules, that were loaded before. > > > Impressive. Not only does it boot faster (with selinux=0), but I can't > see any real difference between 076-1 and 075-4: exactly the same > modules get loaded. > well, did you update initscripts also? From pjones at redhat.com Tue Dec 13 16:48:18 2005 From: pjones at redhat.com (Peter Jones) Date: Tue, 13 Dec 2005 11:48:18 -0500 Subject: call for testing, dmraid in rawhide In-Reply-To: <200512131123.jBDBN9bX008500@porkchop.devel.redhat.com> References: <200512131123.jBDBN9bX008500@porkchop.devel.redhat.com> Message-ID: <1134492498.3089.11.camel@localhost.localdomain> On Tue, 2005-12-13 at 06:23 -0500, Build System wrote: > anaconda-10.90.18-1 ... > * Sun Dec 11 2005 Peter Jones - 10.90.17-1 > - Full dmraid support. (still disabled by default) As the changelog says, last night's rawhide build has support for dmraid during installation. If anybody wants to test this, I'd be really appreciative ;) A couple of ground rules/caveats: 1) Right now on a default install /boot doesn't get mounted after install. In general, "mount -a" doesn't work just yet, and "fsck -a" probably has similar issues. Changing fstab to point at the device instead of a label will probably fix it (I haven't tried that yet ;) 2) It's expecting a partition table on the raid, not a raid on a partition. AFAIK this is how all BIOSes actually lay out the metadata, so that should be normal 3) RAID 0, 1, and (in some cases with some BIOSes) RAID 1+0 only. No RAID 5 or RAID 6 yet, even if your BIOS does it. 4) You'll probably get a nasty failure if you're doing RAID 1 and your drives aren't synced already. (Heinz, we probably should discuss this some) 5) If you move disks that have RAID metadata onto a controller/BIOS that doesn't support it, the installer is still going to think they're perfectly good, and it'll install grub on them, etc. Don't do that. It won't work. 6) If you've added support already and you do an upgrade, it almost certainly won't work. I've got no intention of making this work, either. Sorry. 7) Bug reports should go to bugzilla.redhat.com . File them against anaconda; if they need to be assigned somewhere else, we'll reassign it. So, without further fanfare: To enable this, add "dmraid" to the installer boot command line. -- Peter From i.pilcher at comcast.net Tue Dec 13 17:23:11 2005 From: i.pilcher at comcast.net (Ian Pilcher) Date: Tue, 13 Dec 2005 11:23:11 -0600 Subject: rhn-applet replacement... In-Reply-To: <1134480376.8843.9.camel@defiant> References: <1134480376.8843.9.camel@defiant> Message-ID: Mario Pascucci wrote: > If someone is interested, I'm happy to share this very simple script. Why not post it here (if it's truly a simple script)? I think that there will be a lot of interest. -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From patmans at us.ibm.com Tue Dec 13 18:30:14 2005 From: patmans at us.ibm.com (Patrick Mansfield) Date: Tue, 13 Dec 2005 10:30:14 -0800 Subject: install problem with fc devel as of dec 10 In-Reply-To: <1134490433.23818.6.camel@bree.local.net> References: <20051213015917.GA14560@us.ibm.com> <20051213023350.GA9745@wolves.durham.nc.us> <1134490433.23818.6.camel@bree.local.net> Message-ID: <20051213183014.GA23937@us.ibm.com> On Tue, Dec 13, 2005 at 11:13:53AM -0500, Jeremy Katz wrote: > On Mon, 2005-12-12 at 21:33 -0500, G.Wolfe Woodbury wrote: > > On Mon, Dec 12, 2005 at 05:59:17PM -0800, Patrick Mansfield wrote: > > ..... > > > > > The main thing I notice is this dmesg output: > > > > > > audit(1134461372.947:68): avc: denied { execmem } for pid=9577 comm="grub" scontext=system_u:system_r:anaconda_t:s0 tcontext=system_u:system_r:anaconda_t:s0 tclass=process > > > > > > I would think something would have been output to the gui or serial line > > > if grub failed to run/install. > > Remember, anaconda runs in permissive mode. So any "denials" are just > "this would have been denied", not "this was denied". Mostly because > we're in a very strange environment and things would blow up horribly > otherwise ;) But we have to have policy somewhat loaded as otherwise, > the file contexts aren't known to the kernel for setting the xattrs. > > > No, selinux is interfering with the reboot because no contexts have been > > yet set for the system(?) > > selinux=0 is needed because the policy package didn't have correct > requirements on things it ran in its scripts. I've hopefully got that > fixed up today, but Chris saw something else weird when he tried an > install a little bit ago. So we'll be taking a look at that. I haven't been able to tell if selinux=0 worked or not on that x86 netfinity box (have to check on the console of that machine when/if I go into the office+lab today). In the meantime, I tried a ppc install to a system (blade, JS20) where I can actually do a network install and more easily use a serial line (though the serial over LAN on it is often painful). Same there, it did not reboot (more precisley, it did not shutdown). Seems that a parent anaconda process never goes away, maybe it is held in place by the forked process that opens the shell? Looks like anconda should use "!child" so the parent process is the main process, though I don't understand how anaconda initiates shutdown. I don't know why others (on this thread) didn't hit this problem. That is (untested): diff -uprN -X /home/patman/dontdiff anaconda-10.90.16/anaconda child-anaconda-10.90.16/anaconda --- anaconda-10.90.16/anaconda 2005-12-08 19:11:38.000000000 -0800 +++ child-anaconda-10.90.16/anaconda 2005-12-13 10:18:05.000000000 -0800 @@ -977,7 +977,7 @@ if display_mode == 'g' and flags.usevnc: vncconnecthost=vncconnecthost, vncconnectport=vncconnectport) child = os.fork() - if (child): + if (!child): while 1: print _("Press for a shell") sys.stdin.readline() After killing the one remaining anaconda process, the shutdown proceeded as expected, and first boot worked fine, without selinux=0. I am fairly impressed, everything seems ok on this JS20: Fedora Core release 4 (Rawhide) Kernel 2.6.14-1.1756_FC5 on an ppc64 elm3a229 login: root Password: [root at elm3a229 ~]# uname -a Linux elm3a229 2.6.14-1.1756_FC5 #1 SMP Mon Dec 12 14:43:09 EST 2005 ppc64 ppc64 ppc64 GNU/Linux Guess I'll try some iscsi stuff on it instead, rather than using the old netfinity box. -- Patrick Mansfield From mharris at mharris.ca Tue Dec 13 18:38:09 2005 From: mharris at mharris.ca (Mike A. Harris) Date: Tue, 13 Dec 2005 13:38:09 -0500 Subject: Default cursor theme for FC5. Message-ID: <439F1511.308@mharris.ca> I asked in IRC but didn't get a response, so lets try this asynchronous thingie instead.... In previous OS releases, the default cursor theme was called "BlueCurve" and was configured in host.def in monolithic X packaging. In modular X, the upstream default doesn't configure anything or even install the default cursor theme files. My current running assumption, is that manually hacking this to be like it was before is the correct thing to do for now, however since I haven't seen anyone complain or file any bug reports, I'm wondering if we now override the cursor settings via Gconf or something else? So: Should the default cursor theme remain "BlueCurve", and if so, is it prefered that the libXcursor package supply the /usr/share/icons/default/index.theme file in by default and set this up? I'll update the package once I get some feedback. Thanks in advance. -- Mike A. Harris, Open Source Advocate * http://mharris.ca Proud to be Canadian. From felipe.alfaro at gmail.com Tue Dec 13 19:47:59 2005 From: felipe.alfaro at gmail.com (Felipe Alfaro Solana) Date: Tue, 13 Dec 2005 20:47:59 +0100 Subject: udev alpha testing In-Reply-To: <439EFA70.2010400@redhat.com> References: <438C656B.2080701@redhat.com> <6f6293f10511291124v44f27863p8e5cca2a4973d2a6@mail.gmail.com> <439EFA70.2010400@redhat.com> Message-ID: <6f6293f10512131147s4190f99bx72e5048dc19c28ed@mail.gmail.com> > well, did you update initscripts also? Of course :-) From tmus at tmus.dk Tue Dec 13 20:44:50 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Tue, 13 Dec 2005 21:44:50 +0100 Subject: Default cursor theme for FC5. In-Reply-To: <439F1511.308@mharris.ca> References: <439F1511.308@mharris.ca> Message-ID: Mike A. Harris wrote: > > My current running assumption, is that manually hacking this > to be like it was before is the correct thing to do for now, > however since I haven't seen anyone complain or file any bug > reports, I'm wondering if we now override the cursor settings > via Gconf or something else? > Last time i checked this was still set by the theme files. > > So: Should the default cursor theme remain "BlueCurve", and IMHO, we should definitely get away from the current cursor theme, wherever it's coming from. The reason being that it's blue, which i feel goes bad as a mouse theme. Also i feel that the busy indicator is too "busy". I like the bluecurve theme, but something like jimmac's cursor theme (i think it can be found on gnome-look.org (i think it's called jimmac0) if you're are at all interested. > if so, is it prefered that the libXcursor package supply the > /usr/share/icons/default/index.theme file in by default and > set this up? I think so. previously this has belonged to the xorg-x11 package, but since we're modulizing, this seems fine to me. /Thomas From jam at zoidtechnologies.com Tue Dec 13 21:06:32 2005 From: jam at zoidtechnologies.com (Jeff MacDonald) Date: Tue, 13 Dec 2005 16:06:32 -0500 Subject: rhn-applet replacement... In-Reply-To: <1134480376.8843.9.camel@defiant> References: <1134480376.8843.9.camel@defiant> Message-ID: <1134507992.25547.191.camel@dionysus.zoidtechnologies.com> On Tue, 2005-12-13 at 14:26 +0100, Mario Pascucci wrote: > I've installed Fedora Core 4, and I found that rhn-applet alert icon is > not working at all. > Playing with bash scripting, I've made a very simple script that checks > via "sudoed" command 'yum check-update' for updates and display an icon > on the Gnome panel "notification area" applet using Zenity. > > It's a very poor method, but it works... > If someone is interested, I'm happy to share this very simple script. > HTH > yes, please post to the list with your script. regards, J -- Jeff MacDonald Zoid Technologies, http://zoidtechnologies.com/ From jk at lutty.net Tue Dec 13 20:56:52 2005 From: jk at lutty.net (Laurent Jacquot) Date: Tue, 13 Dec 2005 21:56:52 +0100 Subject: call for testing, dmraid in rawhide In-Reply-To: <1134492498.3089.11.camel@localhost.localdomain> References: <200512131123.jBDBN9bX008500@porkchop.devel.redhat.com> <1134492498.3089.11.camel@localhost.localdomain> Message-ID: <1134507412.25462.32.camel@www.lutty.net> hello, Le mardi 13 d?cembre 2005 ? 11:48 -0500, Peter Jones a ?crit : > On Tue, 2005-12-13 at 06:23 -0500, Build System wrote: > > > anaconda-10.90.18-1 > ... > > * Sun Dec 11 2005 Peter Jones - 10.90.17-1 > > - Full dmraid support. (still disabled by default) > > As the changelog says, last night's rawhide build has support for dmraid > during installation. If anybody wants to test this, I'd be really > appreciative ;) > > A couple of ground rules/caveats: > > 1) Right now on a default install /boot doesn't get mounted after > install. In general, > "mount -a" doesn't work just yet, and "fsck -a" probably has similar > issues. Changing > fstab to point at the device instead of a label will probably fix it > (I haven't tried > that yet ;) > 2) It's expecting a partition table on the raid, not a raid on a > partition. AFAIK this > is how all BIOSes actually lay out the metadata, so that should be > normal > 3) RAID 0, 1, and (in some cases with some BIOSes) RAID 1+0 only. No > RAID 5 or RAID 6 > yet, even if your BIOS does it. > 4) You'll probably get a nasty failure if you're doing RAID 1 and your > drives aren't > synced already. (Heinz, we probably should discuss this some) > 5) If you move disks that have RAID metadata onto a controller/BIOS that > doesn't support > it, the installer is still going to think they're perfectly good, and > it'll install > grub on them, etc. Don't do that. It won't work. > 6) If you've added support already and you do an upgrade, it almost > certainly won't > work. I've got no intention of making this work, either. Sorry. > 7) Bug reports should go to bugzilla.redhat.com . File them against > anaconda; if they > need to be assigned somewhere else, we'll reassign it. > > So, without further fanfare: > > To enable this, add "dmraid" to the installer boot command line. > > -- > Peter > My box is installed there on two sata disk: [root at jack ~]# dmraid -r /dev/sda: nvidia, "nvidia_egeafiab", mirror, ok, 390721966 sectors, data@ 0 /dev/sdb: nvidia, "nvidia_egeafiab", mirror, ok, 390721966 sectors, data@ 0 [root at jack ~]# cat /proc/mdstat Personalities : [raid1] md0 : active raid1 sdb1[1] sda1[0] 1020032 blocks [2/2] [UU] md3 : active raid1 sdb5[1] sda5[0] 152360320 blocks [2/2] [UU] md1 : active raid1 sdb2[1] sda2[0] 40957632 blocks [2/2] [UU] unused devices: This is software raid without BIOS help, and I'm using lvm on those raid devices. [root at jack ~]# pvs PV VG Fmt Attr PSize PFree /dev/md1 rootvg lvm2 a- 39,03G 13,19G /dev/md3 datavg lvm2 a- 145,28G 0 and md0 is an ext3 /boot What do you mean in "2)"? I have partition tables on the raid (lvm stuff) _and_ raid on partitions.. Is this supported, am I failing in the 6) category? I was planning a reinstall but cannot afford loosing datavg TIA Laurent From jk at lutty.net Tue Dec 13 20:28:15 2005 From: jk at lutty.net (Laurent Jacquot) Date: Tue, 13 Dec 2005 21:28:15 +0100 Subject: Default cursor theme for FC5. In-Reply-To: <439F1511.308@mharris.ca> References: <439F1511.308@mharris.ca> Message-ID: <1134505695.25462.26.camel@www.lutty.net> Le mardi 13 d?cembre 2005 ? 13:38 -0500, Mike A. Harris a ?crit : > I asked in IRC but didn't get a response, so lets try this > asynchronous thingie instead.... > > In previous OS releases, the default cursor theme was called > "BlueCurve" and was configured in host.def in monolithic X > packaging. In modular X, the upstream default doesn't configure > anything or even install the default cursor theme files. > > My current running assumption, is that manually hacking this > to be like it was before is the correct thing to do for now, > however since I haven't seen anyone complain or file any bug > reports, I'm wondering if we now override the cursor settings > via Gconf or something else? I was wondering why the cursor theme disapeared on my box recently I tried manualy edit the /desktop/gnome/peripherals/mouse/cursor_theme gconf key but it ended with a half working cursor (mix between the theme and the default). > > So: Should the default cursor theme remain "BlueCurve", and > if so, is it prefered that the libXcursor package supply the > /usr/share/icons/default/index.theme file in by default and > set this up? #ls /usr/share/icons/default/index.* /usr/share/icons/default/index.theme.rpmnew # cat /usr/share/icons/default/index.theme.rpmnew [Icon Theme] Inherits=Bluecurve restoring the file & relogging doesn't give me my cursors back.. > > I'll update the package once I get some feedback. I guess it's poor feedback, but if you have any clue how to make it working.. > Thanks in advance. > > > -- > Mike A. Harris, Open Source Advocate * http://mharris.ca > Proud to be Canadian. > -- Laurent From laroche at redhat.com Tue Dec 13 22:39:23 2005 From: laroche at redhat.com (Florian La Roche) Date: Tue, 13 Dec 2005 23:39:23 +0100 Subject: qemu installs of FC4 via serial console Message-ID: <20051213223923.GA4746@dudweiler.stuttgart.redhat.com> I've finished my first installation of Fedora Core 4 with qemu. This took about 75 minutes for 820 rpm packages on a P4 2.4GHz with qemu configured to have 384MB of RAM. Using "-kernel/-initrd" did not work for me, so I put together a new ISO image which is setting all syslinux options correctly. Configuring qemu to only use a serial console, I can now automatically install and start it e.g. within "screen" and keep it running there. Then I only login via ssh to get some work done. Let me know if you run the below script also for ppc/x86_64 and/or for other releases and how those work. regards, Florian La Roche #!/bin/sh # # Install and run Fedora Core 4 with qemu. # # kickstart file to use KS="ks=http://192.168.123.128/mirror/ks.cfg" # image file to use as harddisk IMAGE=fc4.vmdk # network MAC address to use #MAC="-macaddr d0:0f:af:fe:10:00 52:54:00:12:34:56" # directory where to find Fedora Core FEDORA=/var/www/html/mirror/fedora/4/i386/os test -d $FEDORA || FEDORA=/home/mirror/fedora/4/i386/os PXE=$FEDORA/images/pxeboot # install params for a serial console APPEND="initrd=initrd.img ramdisk_size=8192 text console=ttyS0,9600n8" APPEND="$APPEND utf8 selinux=0 $KS clock=pit" # Do we want to start a new installation? if test "$1" = "install" ; then # Sanity check. test -d $FEDORA || exit 1 test -d $PXE || exit 1 # Create an empty harddisk image: test -f $IMAGE || qemu-img create $IMAGE 6G # The following is not working for me, not sure why: #qemu $MAC -m 384 -nographic -kernel $PXE/vmlinuz \ # -initrd $PXE/initrd.img -append "$APPEND" -hda $IMAGE # Use this for normall install options with a real console: #qemu $MAC -m 384 -serial stdio -cdrom $FEDORA/images/boot.iso \ # -hda $IMAGE -boot d # Copy boot data into a new directory: BOOTDIR=`mktemp -d bootdirXXXXXX` BOOTISO=`mktemp bootXXXXXX.iso` cp -r $FEDORA/isolinux $BOOTDIR/ chmod 644 $BOOTDIR/isolinux/* sed -i -e "s/^timeout .*/timeout 5/" $BOOTDIR/isolinux/isolinux.cfg sed -i -e "s#^ append .*# append $APPEND#" $BOOTDIR/isolinux/isolinux.cfg #cat $BOOTDIR/isolinux/isolinux.cfg mkisofs -quiet -o $BOOTISO -b isolinux/isolinux.bin -c isolinux/boot.cat \ -no-emul-boot -boot-load-size 4 -boot-info-table -R -J \ -V "serial console install" -T $BOOTDIR rm -rf $BOOTDIR time qemu $MAC -m 384 -nographic -cdrom $BOOTISO -hda $IMAGE -boot d rm -rf $BOOTISO exit 0 fi qemu $MAC -m 256 -nographic -hda $IMAGE exit 0 # Things todo within the installed system: # - Modify /etc/inittab to start a serial getty: # s0:12345:respawn:/sbin/agetty 9600 ttyS0 linux # s0:12345:respawn:/sbin/mgetty -r -s 9600 /dev/ttyS0 linux # - Modify /boot/grub/grub.conf: # #splashimage=(hd0,0)/grub/splash.xpm.gz # serial ?unit=0 ?speed=9600 # terminal ?timeout=10 --dump --lines=24 --silent serial console # - Modify grub.conf to have "console=tty0 console=ttyS0,9600n8" # to output kernel messages on both consoles, last entry is # also used for keyboard input. # - Modify /etc/securetty to include your serial device. # TODO: # - Try 38400 or 115200 as speed of the serial port? From ihok at hotmail.com Tue Dec 13 22:42:11 2005 From: ihok at hotmail.com (Jack Tanner) Date: Tue, 13 Dec 2005 17:42:11 -0500 Subject: funny user moment (and perhaps a bug) Message-ID: I just had an amusing moment with FC4, and while I don't know if this is actually a bug in any component, it made for an unexpected experience. Take it or leave it. I'm sitting a few feet away from the FC4 box. I'm logged into Gnome, and I'm playing an audio CD with the Gnome CD Player applet (2.10.2), a.k.a. the local session. I'm also logged into the same FC4 box via NX, which is also running a separate Gnome (a.k.a. the remote session). I eject the CD, and put in another. Both the local and the remote sessions get their own CD Players, and both CD Players seem to be "playing" the CD (the song position dragger is moving in both), and both show the correct CDDB entry. I stop and play the CD using the CD Player in the remote session. It stops, and starts as it should. The CD Player in the local session is now out of synch -- it detects the "stop", but not the "play". There were two unexpected things in this tale: first, the "remote" Gnome session shouldn't have gotten a CD Player (if only because I didn't try to forward audio in my NX settings, for one, but there are also probably security considerations about console owners and such). Second, the "local" CD Player should've been in synch with what was going on with the CD (e.g., track changes were not reflected). If any of these are actual bugs, please tell me the components and I'll file them. From jspaleta at gmail.com Tue Dec 13 22:58:27 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 13 Dec 2005 17:58:27 -0500 Subject: funny user moment (and perhaps a bug) In-Reply-To: References: Message-ID: <604aa7910512131458o444fd787o73302d58233da713@mail.gmail.com> On 12/13/05, Jack Tanner wrote: > If any of these are actual bugs, please tell me the components and I'll > file them. I don't know if there is any technical mechanism to tell the first gnome session from the session exported over NX. Both sessions are really just 2 local gnome sessions being run by the same user. I imagine if you started a second session via gdmflexiserver and login as the same user or start up a vncserver with a gnome desktop it should behave similarly to the original session. Both your sessions are the same user and the "console" concept as used by pam tracks username so I'm not sure how you would restrict the first session as special unless there is some special commandline magic you can pass to gnome-session that I am unaware of. If there is a bug here it probably has to do with the fact that the cd-player application itself gets out of sync across multiple invocations. Can you reproduce this by starting 2 gnome-cd instances in the same gnome session? -jef From ihok at hotmail.com Tue Dec 13 22:58:06 2005 From: ihok at hotmail.com (Jack Tanner) Date: Tue, 13 Dec 2005 17:58:06 -0500 Subject: funny user moment (and perhaps a bug) In-Reply-To: References: Message-ID: Jack Tanner wrote: > I just had an amusing moment with FC4, and while I don't know if this is > actually a bug in any component, it made for an unexpected experience. > Take it or leave it. This addendum I'm pretty sure actually is a bug: when I logged out of the "local" session, I couldn't use the CD Player to eject the CD any more. From tmraz at redhat.com Tue Dec 13 23:08:01 2005 From: tmraz at redhat.com (Tomas Mraz) Date: Wed, 14 Dec 2005 00:08:01 +0100 Subject: funny user moment (and perhaps a bug) In-Reply-To: References: Message-ID: <1134515281.3056.9.camel@perun.redhat.usu> On Tue, 2005-12-13 at 17:58 -0500, Jack Tanner wrote: > Jack Tanner wrote: > > I just had an amusing moment with FC4, and while I don't know if this is > > actually a bug in any component, it made for an unexpected experience. > > Take it or leave it. > > This addendum I'm pretty sure actually is a bug: when I logged out of > the "local" session, I couldn't use the CD Player to eject the CD any more. Well, it isn't. It is a feature of pam_console again. It tracks only local sessions and removes the rights on the device when you log out of it. -- Tomas Mraz From jspaleta at gmail.com Tue Dec 13 23:08:08 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 13 Dec 2005 18:08:08 -0500 Subject: gstreamer 0.10 In-Reply-To: <1134100748.11873.9.camel@localhost.localdomain> References: <1134100748.11873.9.camel@localhost.localdomain> Message-ID: <604aa7910512131508i6bda73a7te6788c2b6155fc1e@mail.gmail.com> On 12/8/05, John (J5) Palmieri wrote: > On Thu, 2005-12-08 at 13:54 -0600, Jason Dravet wrote: > > Is gstreamer 0.10 going to be in FC5T2? > > That depends if we have applications that are ported to it. As it is I > would say that it should go into extras first. If a significant portion > of core apps start depending on 0.10 then we can pull it in. I'm interested in knowing if performance enhancements to the ximagesrc element have been made in gst 0.10. Performance benefits there might make it worthwhile with using with istanbul to make usable fedora videos to suppliment documentation efforts. -jef From wcooley at nakedape.cc Tue Dec 13 23:37:29 2005 From: wcooley at nakedape.cc (Wil Cooley) Date: Tue, 13 Dec 2005 15:37:29 -0800 Subject: "yum --partial" feature as a bash line In-Reply-To: <439C0C8A.9090002@interia.pl> References: <439C0C8A.9090002@interia.pl> Message-ID: <1134517049.28114.65.camel@willow.odshp.com> On Sun, 2005-12-11 at 12:24 +0100, cybernet at interia.pl wrote: > # get a list of items > # remove 4 lines from top (tac/head/tac) > # try to update one item at a time > for k in `yum list updates | awk '{ print $1 }' | tac | head -n-4 | > tac`; do yum -y update > $k; done UUOTac? Try "sed '1,4d'" instead of the tac|head|tac stuff. Or better, use an awk range to filter the output: awk '/^Setting up/,/^Updated Packages/{next};{print $1}' Although this might be better, because it could be used with '-e 0 -d 0' consistently: awk 'FNR==1,/^Updated Packages/ {next}; {print}' Wil -- Wil Cooley Naked Ape Consulting, Ltd -------------- 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 Wed Dec 14 00:13:09 2005 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 13 Dec 2005 16:13:09 -0800 Subject: rawhide java still broken Message-ID: <1134519189.29837.16.camel@yoda.loki.me> I made a lot of headway, but not complete. Tomorrow's rawhide java stuff will still be broken. Sorry for the delay on this folks. -- Jesse Keating Release Engineer: Fedora From n0dalus+redhat at gmail.com Wed Dec 14 00:46:01 2005 From: n0dalus+redhat at gmail.com (n0dalus) Date: Wed, 14 Dec 2005 11:16:01 +1030 Subject: Default cursor theme for FC5. In-Reply-To: <1134505695.25462.26.camel@www.lutty.net> References: <439F1511.308@mharris.ca> <1134505695.25462.26.camel@www.lutty.net> Message-ID: <6280325c0512131646l149e002fq357daba8dea1ce93@mail.gmail.com> On 12/14/05, Laurent Jacquot wrote: > > I was wondering why the cursor theme disapeared on my box recently > I tried manualy edit the /desktop/gnome/peripherals/mouse/cursor_theme > gconf key but it ended with a half working cursor (mix between the theme > and the default). > I've had this problem since I first installed FC5. At first it was the default X cursor all the time, then I changed the cursor theme from BlueCurve and then back again. That made the cursor work more of the time, but still every now and then it reverts to the default X cursors for no good reason. n0dalus. From pjones at redhat.com Wed Dec 14 01:15:30 2005 From: pjones at redhat.com (Peter Jones) Date: Tue, 13 Dec 2005 20:15:30 -0500 Subject: call for testing, dmraid in rawhide In-Reply-To: <1134505485.25462.23.camel@www.lutty.net> References: <200512131123.jBDBN9bX008500@porkchop.devel.redhat.com> <1134492498.3089.11.camel@localhost.localdomain> <1134505485.25462.23.camel@www.lutty.net> Message-ID: <1134522930.3868.3.camel@localhost.localdomain> On Tue, 2005-12-13 at 21:24 +0100, Alexandra Jacquot wrote: > My box is installed there on two sata disk: > [root at jack ~]# dmraid -r > /dev/sda: nvidia, "nvidia_egeafiab", mirror, ok, 390721966 sectors, > data@ 0 > /dev/sdb: nvidia, "nvidia_egeafiab", mirror, ok, 390721966 sectors, > data@ 0 Ok, so this is a dmraid which is BIOS assisted, and so we'd treat it as 1 disk... [ stuff about normal software raid trimmed ] > What do you mean in "2)"? I have partition tables on the raid (lvm > stuff) _and_ raid on partitions.. #2 in my caveats is specifically about bios-supported raid. Putting perfectly normal logical volumes or software raids on top of dmraid devices should work fine. > Is this supported, am I failing in the 6) category? I was planning a > reinstall but cannot afford loosing datavg If you can't afford to lose data, rawhide isn't for you. -- Peter From philipp_subx at redfish-solutions.com Wed Dec 14 01:28:27 2005 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Tue, 13 Dec 2005 18:28:27 -0700 Subject: TB: Issues building 1.0.7 on FC3 (fails for i386, works for x86_64) Message-ID: <439F753B.2070903@redfish-solutions.com> I'm trying to build the SRPM for thunderbird-1.0.7-1.1.fc3, and it works fine on x86_64, but it fails for i386. It complains that it can't find xproto, which is required for Xft. ?!?!? Any ideas? Thanks, -Philip ... + make -f client.mk build_all Adding client.mk options from /home/src/redhat/BUILD/mozilla/.mozconfig: MOZ_THUNDERBIRD=1 BUILD_OFFICIAL=1 MOZILLA_OFFICIAL=1 MOZ_MAKE_FLAGS= cd /home/src/redhat/BUILD/mozilla ./configure Adding configure options from ./.mozconfig: --enable-crypto --disable-mathml --disable-activex --disable-activex-scripting --disable-tests --disable-oji --disable-plugins --disable-necko-disk-cache --enable-single-profile --disable-profilesharing --enable-extensions=wallet,spellcheck,xmlextras,webservices --enable-necko-protocols=http,file,jar,viewsource,res,data --enable-image-decoders=default,-xbm --enable-default-toolkit=gtk2 --enable-xft --enable-optimize=-Os -g -pipe -m32 -march=i386 -mtune=pentium4 --with-system-jpeg --with-system-png --with-system-zlib --with-pthreads --enable-freetype2 --enable-xinerama --disable-xprint --disable-debug --disable-strip --disable-tests --enable-official-branding --enable-pango --libdir=/usr/lib --with-default-mozilla-five-home=/usr/lib/thunderbird-1.0.7 creating cache ./config.cache checking host system type... i686-pc-linux-gnu checking target system type... i686-pc-linux-gnu checking build system type... i686-pc-linux-gnu checking for gcc... gcc checking whether the C compiler (gcc -Os -g -pipe -m32 -march=i386 -mtune=pentium4 ) works... yes checking whether the C compiler (gcc -Os -g -pipe -m32 -march=i386 -mtune=pentium4 ) is a cross-compiler... no checking whether we are using GNU C... yes checking whether gcc accepts -g... yes checking for c++... c++ checking whether the C++ compiler (c++ -Os -g -pipe -m32 -march=i386 -mtune=pentium4 ) works... yes checking whether the C++ compiler (c++ -Os -g -pipe -m32 -march=i386 -mtune=pentium4 ) is a cross-compiler... no checking whether we are using GNU C++... yes checking whether c++ accepts -g... yes checking for ranlib... ranlib checking for as... /usr/bin/as checking for ar... ar checking for ld... ld checking for strip... strip checking for windres... no checking for gawk... gawk checking whether gcc and cc understand -c and -o together... yes checking how to run the C preprocessor... gcc -E checking how to run the C++ preprocessor... c++ -E checking for a BSD compatible install... /usr/bin/install -c checking whether ln -s works... yes checking for perl5... no checking for perl... /usr/bin/perl checking for minimum required perl version >= 5.004... 5.008005 checking for full perl installation... yes checking for doxygen... /usr/bin/doxygen checking for whoami... /usr/bin/whoami checking for autoconf... /usr/bin/autoconf checking for unzip... /usr/bin/unzip checking for zip... /usr/bin/zip checking for makedepend... /usr/X11R6/bin/makedepend checking for xargs... /usr/bin/xargs checking for gmake... /usr/bin/gmake checking for X... libraries /usr/X11R6/lib, headers /usr/X11R6/include checking for dnet_ntoa in -ldnet... no checking for dnet_ntoa in -ldnet_stub... no checking for gethostbyname... yes checking for connect... yes checking for remove... yes checking for shmat... yes checking for IceConnectionNumber in -lICE... yes checking whether ld has archive extraction flags... yes checking for 64-bit OS... no checking for ANSI C header files... yes checking for working const... yes checking for mode_t... yes checking for off_t... yes checking for pid_t... yes checking for size_t... yes checking for uid_t in sys/types.h... yes checking for st_blksize in struct stat... yes checking for siginfo_t... yes checking for int16_t... yes checking for int32_t... yes checking for int64_t... yes checking for int64... no checking for uint... yes checking for uint_t... no checking for uint16_t... no checking for uname.domainname... yes checking for uname.__domainname... no checking for usable wchar_t (2 bytes, unsigned)... no checking for compiler -fshort-wchar option... yes checking for .hidden assembler directive... yes checking whether __attribute__((visibility())) is supported... yes checking for dirent.h that defines DIR... yes checking for opendir in -ldir... no checking for sys/byteorder.h... no checking for compat.h... no checking for getopt.h... yes checking for sys/bitypes.h... yes checking for memory.h... yes checking for unistd.h... yes checking for gnu/libc-version.h... yes checking for nl_types.h... yes checking for malloc.h... yes checking for X11/XKBlib.h... yes checking for sys/statvfs.h... yes checking for sys/statfs.h... yes checking for sys/vfs.h... yes checking for sys/mount.h... yes checking for mmintrin.h... no checking for new... yes checking for sys/cdefs.h... yes checking for gethostbyname_r in -lc_r... no checking for atan in -lm... yes checking for dlopen in -ldl... yes checking for dlfcn.h... yes checking for socket in -lsocket... no checking for XDrawLines in -lX11... yes checking for XextAddDisplay in -lXext... yes checking for XtFree in -lXt... yes checking for XineramaIsActive in -lXinerama... yes checking for X11/extensions/Xinerama.h... yes checking for XShmCreateImage in -lXext... yes checking for X11/extensions/XShm.h... yes checking for XieFloGeometry in -lXIE... no checking for X11/extensions/XIElib.h... no checking for freetype-config... /usr/bin/freetype-config checking for FreeType - version >= 6.1.0... yes checking for pthread_create in -lpthreads... no checking for pthread_create in -lpthread... yes checking whether gcc accepts -pthread... yes checking whether mmap() sees write()s... yes checking whether gcc needs -traditional... no checking for 8-bit clean memcmp... yes checking for random... yes checking for strerror... yes checking for lchown... yes checking for fchmod... yes checking for snprintf... yes checking for statvfs... yes checking for memmove... yes checking for rint... yes checking for flockfile... yes checking for getpagesize... yes checking for localtime_r... yes checking for strtok_r... yes checking for wcrtomb... yes checking for mbrtowc... yes checking for res_ninit()... yes checking for gnu_get_libc_version()... yes checking for iconv in -lc... yes checking for iconv()... yes checking for iconv() with const input... no checking for nl_langinfo and CODESET... yes checking for an implementation of va_copy()... yes checking for an implementation of __va_copy()... yes checking whether va_lists can be copied by value... yes checking for C++ exceptions flag... -fno-exceptions checking for gcc 3.0 ABI... yes checking for C++ "explicit" keyword... yes checking for C++ "typename" keyword... yes checking for modern C++ template specialization syntax support... yes checking whether partial template specialization works... yes checking whether operators must be re-defined for templates derived from templates... no checking whether we need to cast a derived template to pass as its base class... no checking whether the compiler can resolve const ambiguities for templates... yeschecking whether the C++ "using" keyword can change access... yes checking whether the C++ "using" keyword resolves ambiguity... yes checking for "std::" namespace... yes checking whether standard template operator!=() is ambiguous... unambiguous checking for C++ reinterpret_cast... yes checking for C++ dynamic_cast to void*... yes checking whether C++ requires implementation of unused virtual methods... no checking for trouble comparing to zero near std::operator!=()... no checking for LC_MESSAGES... yes checking for jpeg_destroy_compress in -ljpeg... yes checking for gzread in -lz... yes checking for png_get_valid in -lpng... yes checking for pkg-config... /usr/bin/pkg-config checking for gtk+-2.0 >= 1.3.7... yes checking MOZ_GTK2_CFLAGS... -DXTHREADS -D_REENTRANT -DXUSE_MTSAFE_API -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/X11R6/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/include/freetype2/config -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include checking MOZ_GTK2_LIBS... -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgdk_pixbuf-2.0 -lm -lpangoxft-1.0 -lpangox-1.0 -lpango-1.0 -lgobject-2.0 -lgmodule-2.0 -ldl -lglib-2.0 checking for xft... Package xproto was not found in the pkg-config search path. Perhaps you should add the directory containing `xproto.pc' to the PKG_CONFIG_PATH environment variable Package 'xproto', required by 'Xft', not found configure: error: Library requirements (xft) not met; consider adjusting the PKG_CONFIG_PATH environment variable if your libraries are in a nonstandard prefix so pkg-config can find them. *** Fix above errors and then restart with "make -f client.mk build" make: *** [/home/src/redhat/BUILD/mozilla/Makefile] Error 1 error: Bad exit status from /var/tmp/rpm-tmp.60007 (%build) RPM build errors: Bad exit status from /var/tmp/rpm-tmp.60007 (%build) [root at settop SPECS]# From michael.favia at insitesinc.com Wed Dec 14 06:05:02 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Wed, 14 Dec 2005 00:05:02 -0600 Subject: rawhide java still broken In-Reply-To: <1134519189.29837.16.camel@yoda.loki.me> References: <1134519189.29837.16.camel@yoda.loki.me> Message-ID: <439FB60E.7010107@insitesinc.com> Jesse Keating wrote: > I made a lot of headway, but not complete. Tomorrow's rawhide java > stuff will still be broken. Sorry for the delay on this folks. Thank you for the heads up. An ounce of prevention saves a lot of explanation to the people who think it is a unique problem to them. -mf From m.f.h at web.de Wed Dec 14 08:18:51 2005 From: m.f.h at web.de (Marcus Hartig) Date: Wed, 14 Dec 2005 09:18:51 +0100 Subject: Default cursor theme for FC5. Message-ID: <439FD56B.8040608@web.de> Hi, and I wonder me, why the Bluecurve cursor is gone. In the Bluecurve index.theme is the line: Inherits=gnome,crystalsvg They both have no cursors and crystalsvg point again to hicolor cursor, gnome to nowhere, line is missing. The jimmac0 theme or alittle package from gnome-look.org would be a good cursor theme. Nice and clean. Marcus From buildsys at redhat.com Wed Dec 14 08:30:57 2005 From: buildsys at redhat.com (Build System) Date: Wed, 14 Dec 2005 03:30:57 -0500 Subject: rawhide report: 20051214 changes Message-ID: <200512140830.jBE8UuHq028440@porkchop.devel.redhat.com> New package agg Anti-Grain Geometry New package opensp SGML and XML parser Updated Packages: ant-0:1.6.5-1jpp_1fc.2 ---------------------- antlr-0:2.7.4-2jpp_4fc.1.1 -------------------------- * Tue Dec 13 2005 Jesse Keating - rebuilt for new gcj bcel-0:5.1-1jpp_4fc.1.1.1.1 --------------------------- * Tue Dec 13 2005 Jesse Keating - rebuilt for new gcj cairo-java-1.0.1-3.1.1.1.1 -------------------------- * Tue Dec 13 2005 Jesse Keating - rebuilt for new gcj cryptix-0:3.2.0-4jpp_2fc.1.1.1.1 -------------------------------- * Tue Dec 13 2005 Jesse Keating - rebuilt for new gcj docbook-dtds-1.0-30 ------------------- * Tue Dec 13 2005 Tim Waugh 1.0-30 - Fix ISO entities in 4.3/4.4 SGML. eel2-2.13.3-1 ------------- * Tue Dec 13 2005 Alexander Larsson 2.13.3-1 - Update to 2.13.3 finger-0.17-31 -------------- * Tue Dec 13 2005 Radek Vokal 0.17-31 - real UTF8 patch by fontconfig-2.3.92.cvs20051129-3 ------------------------------- * Tue Dec 13 2005 Carl Worth - 2.3.92.cvs20051129-3 - Disable hinting for Lohit Gujarati freeradius-1.0.5-1 ------------------ * Tue Dec 13 2005 Thomas Woerner 1.0.5-1 - new version 1.0.5 gjdoc-0.7.6-3 ------------- * Tue Dec 13 2005 Jakub Jelinek 0.7.6-3 - rebuild with gcc-4.1.0-0.7 (non-BC ABI break) glib-java-0.2.1-3.4 ------------------- * Tue Dec 13 2005 Jesse Keating - retry s390x as others require it on that platform gnome-vfs2-2.13.2-1 ------------------- * Tue Dec 13 2005 Alexander Larsson 2.13.2-1 - update to 2.13.2 gnu.getopt-0:1.0.9-4jpp_2fc.1.1.1.1 ----------------------------------- * Tue Dec 13 2005 Jesse Keating - rebuilt for new gcj gnu.regexp-0:1.1.4-7jpp_1fc.1.1 ------------------------------- * Tue Dec 13 2005 Jesse Keating - rebuilt for new gcj hwdata-0.173-1 -------------- * Tue Dec 13 2005 Bill Nottingham - 0.173-1 - add some IDs to the generic display entries for matching laptops * Fri Nov 18 2005 Bill Nottingham - 0.172-1 - ditto for radeon * Fri Nov 18 2005 Jeremy Katz - 0.171-1 - r128 -> ati. should fix the unresolved symbol and kem says its more generally the "right" thing to do iputils-20020927-32 ------------------- * Tue Dec 13 2005 Radek Vokal 20020927-32 - fix HOPLIMIT option for setsockopt() (#175471) jakarta-commons-codec-0:1.3-2jpp_1fc.1.1.1.1 -------------------------------------------- * Tue Dec 13 2005 Jesse Keating - rebuilt for new gcj jakarta-commons-collections-0:3.1-2jpp_2fc.1.1.1.1 -------------------------------------------------- * Tue Dec 13 2005 Jesse Keating - rebuilt for new gcj jakarta-commons-dbcp-0:1.2.1-3jpp_2fc.2.1 ----------------------------------------- jakarta-commons-lang-0:2.0-2jpp_2fc.2 ------------------------------------- * Tue Dec 13 2005 Jesse Keating - 0:2.0-2jpp_2fc.2 - Patched to not use taget= in build.xml * Tue Dec 13 2005 Jesse Keating - rebuilt for new gcj * Fri Dec 09 2005 Jesse Keating - rebuilt jakarta-commons-launcher-0:0.9-3jpp_1fc.1.1 ------------------------------------------- * Tue Dec 13 2005 Jesse Keating - rebuilt for new gcj jakarta-commons-pool-0:1.2-2jpp_2fc.1.1.1.1 ------------------------------------------- * Tue Dec 13 2005 Jesse Keating - rebuilt for new gcj jlex-0:1.2.6-1jpp_2fc.1.1.1.1 ----------------------------- * Tue Dec 13 2005 Jesse Keating - rebuilt for new gcj jsch-0:0.1.18-1jpp_3fc ---------------------- * Tue Dec 13 2005 Andrew Overholt 0.1.18-1jpp_3fc - Rebuild with gcc 4.1. * Fri Dec 09 2005 Jesse Keating - rebuilt junit-0:3.8.1-3jpp_5fc.1.1.1.1 ------------------------------ * Tue Dec 13 2005 Jesse Keating - rebuilt for new gcj kernel-2.6.14-1.1760_FC5 ------------------------ * Tue Dec 13 2005 Dave Jones - 2.6.15-rc5-git3 - Use MMIO instead of PIO for 8139too * Tue Dec 13 2005 David Woodhouse - Remove workaround for fixed GCC PR25248 * Mon Dec 12 2005 Dave Jones - 2.6.15-rc5-git2 libglade-java-2.12.1-2.2 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt libgnome-java-2.12.1-2.1.2 -------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libgnomecanvas-2.12.0-1.2 ------------------------- * Tue Dec 13 2005 Jeremy Katz - 2.12.0-1.2 - rebuild with -O1 to workaround (#175669) libgtk-java-2.8.1-2.1.1 ----------------------- * Tue Dec 13 2005 Jesse Keating - rebuilt for new gcj * Fri Dec 09 2005 Igor Foox - 2.8.1-2 - Version bump to account for gcc4.1. libofx-0.7.0-4 -------------- * Tue Dec 13 2005 Tim Waugh 0.7.0-4 - Build requires: openjade-devel -> opensp-devel. * Fri Dec 09 2005 Jesse Keating - rebuilt libraw1394-1.2.0-3.fc5 ---------------------- * Tue Dec 13 2005 Warren Togami - 1.2.0-3 - disable static and remove .la (#172642) * Fri Dec 09 2005 Jesse Keating - rebuilt libselinux-1.29.1-3 ------------------- * Sun Dec 11 2005 Dan Walsh 1.29.1-3 - update to latest libsetrans - Fix potential memory leak * Fri Dec 09 2005 Jesse Keating - rebuilt * Thu Dec 08 2005 Dan Walsh 1.29.1-1 - Update to never version * Merged patch for swig interfaces from Dan Walsh. libsemanage-1.5.2-1 ------------------- * Tue Dec 13 2005 Dan Walsh 1.5.1-2 - Upgrade to latest from NSA * Merged toggle modified flag in policydb_modify, fix memory leak in clear_obsolete, polymorphism vs headers fix, and include guards for internal headers patches from Ivan Gyurdiev. libvte-java-0.11.11-6.3 ----------------------- log4j-0:1.2.8-7jpp_6fc.2 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt man-1.6b-2 ---------- * Tue Dec 13 2005 Ivana Varekova 1.6b-2 - makewhatis change - add info about packages (bug 175595) * Fri Dec 09 2005 Jesse Keating - rebuilt * Thu Nov 10 2005 Ivana Varekova 1.6b-1 - update to 1.6b mx4j-1:3.0.1-1jpp_5fc.2 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt nanoxml-0:2.2.3-3jpp_3fc.2 -------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt nautilus-2.13.3-1 ----------------- * Tue Dec 13 2005 Alexander Larsson 2.13.3-1 - Update to 2.13.3 * Fri Dec 09 2005 Jesse Keating - rebuilt * Fri Dec 02 2005 Matthias Clasen 2.13.2-1 - Update to 2.13.2 - Update patches oldkilim-0:1.1.3-2jpp_3fc.1.1 ----------------------------- * Tue Dec 13 2005 Jesse Keating - rebuilt for new gcj * Fri Dec 09 2005 Jesse Keating - rebuilt openjade-1.3.2-20 ----------------- * Tue Dec 13 2005 Tim Waugh 1.3.2-20 - Use --enable-splibdir to prevent ambiguity. - Move 'install-catalog --remove' to %preun section (bug #60409). * Thu Dec 08 2005 Terje Bless - 1.3.2-19 - Drop -devel subpackage. * Sun Dec 04 2005 Ville Skytt?? - 1.3.2-18 - Really BuildRequire opensp-devel. - Clean up unneeded build dependencies and configure options. - Drop dependency on docbook-dtds. - Fix %post(un) syntax and catalog installation. openoffice.org-1:2.0.1-145.2.2 ------------------------------ * Thu Dec 08 2005 Caolan McNamara - 1:2.0.1-145.2 - gcc 4.1 rebuild - disable workspace.jaxpapi.patch for now - disable fasterhelpcontent2.patch for now - rh#175272# openoffice.org-2.0.1.ooo59129.vcl.readonlyentry.patch - gcc#25389# File(new URI("file:./")) regression * Thu Dec 08 2005 Caolan McNamara - 1:2.0.1-145.1 - next version * Thu Dec 08 2005 Caolan McNamara - 1:2.0.1-144.1 - openoffice.org-2.0.1.rh175242.connectivity.mozab.patch, provide mozilla address backend despite http://bugzilla.mozilla.org/show_bug.cgi?id=135137 oro-0:2.0.8-1jpp_3fc.1.1.1.1 ---------------------------- * Tue Dec 13 2005 Jesse Keating - rebuilt for new gcj pciutils-2.2.1-1 ---------------- * Tue Dec 13 2005 Bill Nottingham - 2.2.1-1 - update to 2.2.1, adjust patches pcmciautils-011-1 ----------------- * Tue Dec 13 2005 Bill Nottingham 011-1 - update to 011, now ships with its own udev rules - remove pcmcia-cs provide postfix-2:2.2.7-1 ----------------- * Tue Dec 13 2005 Thomas Woerner 2:2.2.7-1 - new version 2.2.7 puretls-0.9-0.b4.1jpp_2fc.1.1.1.1 --------------------------------- * Tue Dec 13 2005 Jesse Keating - rebuilt for new gcj regexp-0:1.3-2jpp_3fc.1.1.1.1 ----------------------------- * Tue Dec 13 2005 Jesse Keating - rebuilt for new gcj * Fri Dec 09 2005 Jesse Keating - rebuilt rhpl-0.179-1.1 -------------- * Tue Dec 13 2005 Chris Lumens 0.179-1.1 - Change pl keymap to pl2. * Fri Dec 09 2005 Jesse Keating - rebuilt selinux-policy-2.1.5-1 ---------------------- * Tue Dec 13 2005 Dan Walsh 2.1.5-1 - Update from upstream - Allow unconfined_t to transition to rpm_script_t * Tue Dec 13 2005 Dan Walsh 2.1.4-2 - Clean up spec - range_transition crond to SystemHigh sox-12.17.9-1 ------------- * Tue Dec 13 2005 Thomas Woerner 12.17.9-1 - new version 12.17.9 * Fri Dec 09 2005 Jesse Keating - rebuilt tanukiwrapper-0:3.1.1-4jpp_3fc.2 -------------------------------- * Tue Dec 13 2005 Jesse Keating - added patch to not use target= in build.xml * Tue Dec 13 2005 Jesse Keating - rebuilt for new gcj * Fri Dec 09 2005 Jesse Keating - rebuilt udev-077-1 ---------- * Tue Dec 13 2005 Harald Hoyer - 077-1 - version 077 - patch to include udevstart2 in udevd and delay daemonize until queue is empty * Fri Dec 09 2005 Jesse Keating - rebuilt usbutils-0.71-1 --------------- * Tue Dec 13 2005 Thomas Woerner 0.71-1 - new version 0.71 * Fri Dec 09 2005 Jesse Keating - rebuilt werken.xpath-0:0.9.4-0.beta.9jpp_1fc.1.1 ---------------------------------------- * Tue Dec 13 2005 Jesse Keating - rebuilt for new gcj * Fri Dec 09 2005 Jesse Keating - rebuilt xerces-j2-0:2.6.2-6jpp_0fc.1.1 ------------------------------ * Tue Dec 13 2005 Jesse Keating - rebuilt for new gcj xml-commons-0:1.0-0.b2.7jpp_3fc.1.1 ----------------------------------- * Tue Dec 13 2005 Jesse Keating - rebuilt for new gcj * Fri Dec 09 2005 Jesse Keating - rebuilt * Fri Jul 15 2005 Gary Benson - 0:1.0-0.b2.7jpp_3fc - Build on ia64, ppc64, s390 and s390x. - Switch to aot-compile-rpm (also BC-compiles the which jar). yum-2.5.0-1 ----------- * Tue Dec 13 2005 Jeremy Katz - 2.5.0-1 - update to 2.5.0 - add patch for traceback in #175647 Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 carol - 1.8.9.3-1jpp_6fc.i386 requires libgcj.so.6 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel = 0:2.6.14-1.1696_FC5 cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5smp cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 eclipse-bugzilla - 1:0.1.1_fc-5.i386 requires libgcj.so.6 eclipse-cdt - 1:3.0.1-1jpp_1fc.i386 requires libgcj.so.6 eclipse-changelog - 1:2.0.1_fc-22.i386 requires libgcj.so.6 eclipse-ecj - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-jdt - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-pde - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-platform - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-pydev - 1:0.9.3_fc-12.i386 requires libgcj.so.6 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel = 0:2.6.14-1.1696_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 gnu-crypto - 2.0.1-1jpp_8fc.i386 requires libgcj.so.6 gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.i386 requires libgcj.so.6 gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.i386 requires libgcj.so.6 jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jotm - 2.0.5-1jpp_3fc.i386 requires libgcj.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.i386 requires libgcjawt.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 lucene - 1.4.3-1jpp_7fc.i386 requires libgcj.so.6 lucene-demo - 1.4.3-1jpp_7fc.i386 requires libgcj.so.6 monolog - 1.8.6-1jpp_5fc.i386 requires libgcj.so.6 p6spy - 1.3-2jpp_3fc.i386 requires libgcj.so.6 struts - 1.2.4-2jpp_3fc.i386 requires libgcj.so.6 struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.i386 requires libgcj.so.6 systemtap - 0.5-2.i386 requires libdw.so.1(ELFUTILS_0.116) tomcat5 - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 tomcat5-admin-webapps - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 tomcat5-jasper - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 tomcat5-webapps - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 xalan-j2 - 2.6.0-3jpp_4fc.i386 requires libgcj.so.6 xalan-j2-demo - 2.6.0-3jpp_4fc.i386 requires libgcj.so.6 xalan-j2-xsltc - 2.6.0-3jpp_4fc.i386 requires libgcj.so.6 Broken deps for ia64 ---------------------------------------------------------- carol - 1.8.9.3-1jpp_6fc.ia64 requires libgcj.so.6()(64bit) gnome-volume-manager - 1.5.4-1.1.ia64 requires kernel >= 0:2.6 gnu-crypto - 2.0.1-1jpp_8fc.ia64 requires libgcj.so.6()(64bit) gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.ia64 requires libgcj.so.6()(64bit) gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.ia64 requires libgcj.so.6()(64bit) jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) jotm - 2.0.5-1jpp_3fc.ia64 requires libgcj.so.6()(64bit) lucene - 1.4.3-1jpp_7fc.ia64 requires libgcj.so.6()(64bit) lucene-demo - 1.4.3-1jpp_7fc.ia64 requires libgcj.so.6()(64bit) monolog - 1.8.6-1jpp_5fc.ia64 requires libgcj.so.6()(64bit) p6spy - 1.3-2jpp_3fc.ia64 requires libgcj.so.6()(64bit) pcmciautils - 011-1.ia64 requires kernel >= 0:2.6.12-1.1411_FC5 rgmanager - 1.9.31-3.ia64 requires ccs struts - 1.2.4-2jpp_3fc.ia64 requires libgcj.so.6()(64bit) struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.ia64 requires libgcj.so.6()(64bit) systemtap - 0.5-2.ia64 requires libdw.so.1(ELFUTILS_0.116)(64bit) systemtap - 0.5-2.ia64 requires kernel >= 0:2.6.9-11 systemtap - 0.5-2.ia64 requires kernel-devel tomcat5 - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) tomcat5-admin-webapps - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) tomcat5-jasper - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) tomcat5-webapps - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) xalan-j2 - 2.6.0-3jpp_4fc.ia64 requires libgcj.so.6()(64bit) xalan-j2-demo - 2.6.0-3jpp_4fc.ia64 requires libgcj.so.6()(64bit) xalan-j2-xsltc - 2.6.0-3jpp_4fc.ia64 requires libgcj.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- carol - 1.8.9.3-1jpp_6fc.ppc requires libgcj.so.6 cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 eclipse-bugzilla - 1:0.1.1_fc-5.ppc requires libgcj.so.6 eclipse-cdt - 1:3.0.1-1jpp_1fc.ppc requires libgcj.so.6 eclipse-changelog - 1:2.0.1_fc-22.ppc requires libgcj.so.6 eclipse-ecj - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-jdt - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-pde - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-platform - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-pydev - 1:0.9.3_fc-12.ppc requires libgcj.so.6 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 gnu-crypto - 2.0.1-1jpp_8fc.ppc requires libgcj.so.6 gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.ppc requires libgcj.so.6 gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.ppc requires libgcj.so.6 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jotm - 2.0.5-1jpp_3fc.ppc requires libgcj.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.ppc requires libgcjawt.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 lucene - 1.4.3-1jpp_7fc.ppc requires libgcj.so.6 lucene-demo - 1.4.3-1jpp_7fc.ppc requires libgcj.so.6 monolog - 1.8.6-1jpp_5fc.ppc requires libgcj.so.6 p6spy - 1.3-2jpp_3fc.ppc requires libgcj.so.6 struts - 1.2.4-2jpp_3fc.ppc requires libgcj.so.6 struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.ppc requires libgcj.so.6 systemtap - 0.5-2.ppc requires libdw.so.1(ELFUTILS_0.116) tomcat5 - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 tomcat5-admin-webapps - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 tomcat5-jasper - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 tomcat5-webapps - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 xalan-j2 - 2.6.0-3jpp_4fc.ppc requires libgcj.so.6 xalan-j2-demo - 2.6.0-3jpp_4fc.ppc requires libgcj.so.6 xalan-j2-xsltc - 2.6.0-3jpp_4fc.ppc requires libgcj.so.6 Broken deps for ppc64 ---------------------------------------------------------- carol - 1.8.9.3-1jpp_6fc.ppc64 requires libgcj.so.6()(64bit) cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 gnu-crypto - 2.0.1-1jpp_8fc.ppc64 requires libgcj.so.6()(64bit) gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.ppc64 requires libgcj.so.6()(64bit) gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.ppc64 requires libgcj.so.6()(64bit) jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) jotm - 2.0.5-1jpp_3fc.ppc64 requires libgcj.so.6()(64bit) lucene - 1.4.3-1jpp_7fc.ppc64 requires libgcj.so.6()(64bit) lucene-demo - 1.4.3-1jpp_7fc.ppc64 requires libgcj.so.6()(64bit) monolog - 1.8.6-1jpp_5fc.ppc64 requires libgcj.so.6()(64bit) p6spy - 1.3-2jpp_3fc.ppc64 requires libgcj.so.6()(64bit) struts - 1.2.4-2jpp_3fc.ppc64 requires libgcj.so.6()(64bit) struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.ppc64 requires libgcj.so.6()(64bit) tomcat5 - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) tomcat5-admin-webapps - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) tomcat5-jasper - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) tomcat5-webapps - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) xalan-j2 - 2.6.0-3jpp_4fc.ppc64 requires libgcj.so.6()(64bit) xalan-j2-demo - 2.6.0-3jpp_4fc.ppc64 requires libgcj.so.6()(64bit) xalan-j2-xsltc - 2.6.0-3jpp_4fc.ppc64 requires libgcj.so.6()(64bit) Broken deps for s390 ---------------------------------------------------------- carol - 1.8.9.3-1jpp_6fc.s390 requires libgcj.so.6 gnu-crypto - 2.0.1-1jpp_8fc.s390 requires libgcj.so.6 gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.s390 requires libgcj.so.6 gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.s390 requires libgcj.so.6 jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jotm - 2.0.5-1jpp_3fc.s390 requires libgcj.so.6 lucene - 1.4.3-1jpp_7fc.s390 requires libgcj.so.6 lucene-demo - 1.4.3-1jpp_7fc.s390 requires libgcj.so.6 monolog - 1.8.6-1jpp_5fc.s390 requires libgcj.so.6 p6spy - 1.3-2jpp_3fc.s390 requires libgcj.so.6 struts - 1.2.4-2jpp_3fc.s390 requires libgcj.so.6 struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.s390 requires libgcj.so.6 tomcat5 - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 tomcat5-admin-webapps - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 tomcat5-jasper - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 tomcat5-webapps - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 xalan-j2 - 2.6.0-3jpp_4fc.s390 requires libgcj.so.6 xalan-j2-demo - 2.6.0-3jpp_4fc.s390 requires libgcj.so.6 xalan-j2-xsltc - 2.6.0-3jpp_4fc.s390 requires libgcj.so.6 Broken deps for s390x ---------------------------------------------------------- carol - 1.8.9.3-1jpp_6fc.s390x requires libgcj.so.6()(64bit) gnu-crypto - 2.0.1-1jpp_8fc.s390x requires libgcj.so.6()(64bit) gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.s390x requires libgcj.so.6()(64bit) gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.s390x requires libgcj.so.6()(64bit) jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) jotm - 2.0.5-1jpp_3fc.s390x requires libgcj.so.6()(64bit) libgconf-java - 2.12.0-2.s390x requires libgcj.so.6()(64bit) libgconf-java - 2.12.0-2.s390x requires libcairojava-1.0.so()(64bit) libglade-java - 2.12.0-5.s390x requires libgcj.so.6()(64bit) libglade-java - 2.12.0-5.s390x requires libcairojava-1.0.so()(64bit) libgnome-java - 2.12.0-2.s390x requires libgcj.so.6()(64bit) libgnome-java - 2.12.0-2.s390x requires libcairojava-1.0.so()(64bit) libgtk-java - 2.8.0-7.s390x requires libgcj.so.6()(64bit) libvte-java - 0.11.11-6.3.s390x requires libcairojava-1.0.so()(64bit) lucene - 1.4.3-1jpp_7fc.s390x requires libgcj.so.6()(64bit) lucene-demo - 1.4.3-1jpp_7fc.s390x requires libgcj.so.6()(64bit) monolog - 1.8.6-1jpp_5fc.s390x requires libgcj.so.6()(64bit) p6spy - 1.3-2jpp_3fc.s390x requires libgcj.so.6()(64bit) struts - 1.2.4-2jpp_3fc.s390x requires libgcj.so.6()(64bit) struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.s390x requires libgcj.so.6()(64bit) tomcat5 - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) tomcat5-admin-webapps - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) tomcat5-jasper - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) tomcat5-webapps - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) xalan-j2 - 2.6.0-3jpp_4fc.s390x requires libgcj.so.6()(64bit) xalan-j2-demo - 2.6.0-3jpp_4fc.s390x requires libgcj.so.6()(64bit) xalan-j2-xsltc - 2.6.0-3jpp_4fc.s390x requires libgcj.so.6()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 carol - 1.8.9.3-1jpp_6fc.x86_64 requires libgcj.so.6()(64bit) cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 eclipse-bugzilla - 1:0.1.1_fc-5.x86_64 requires libgcj.so.6()(64bit) eclipse-cdt - 1:3.0.1-1jpp_1fc.x86_64 requires libgcj.so.6()(64bit) eclipse-changelog - 1:2.0.1_fc-22.x86_64 requires libgcj.so.6()(64bit) eclipse-ecj - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-jdt - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-pde - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-platform - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-pydev - 1:0.9.3_fc-12.x86_64 requires libgcj.so.6()(64bit) gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 gnu-crypto - 2.0.1-1jpp_8fc.x86_64 requires libgcj.so.6()(64bit) gnu-crypto-jce-jdk1.4 - 2.0.1-1jpp_8fc.x86_64 requires libgcj.so.6()(64bit) gnu-crypto-sasl-jdk1.4 - 2.0.1-1jpp_8fc.x86_64 requires libgcj.so.6()(64bit) jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jotm - 2.0.5-1jpp_3fc.x86_64 requires libgcj.so.6()(64bit) libswt3-gtk2 - 1:3.1.1-1jpp_9fc.x86_64 requires libgcjawt.so.6()(64bit) libswt3-gtk2 - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) lucene - 1.4.3-1jpp_7fc.x86_64 requires libgcj.so.6()(64bit) lucene-demo - 1.4.3-1jpp_7fc.x86_64 requires libgcj.so.6()(64bit) monolog - 1.8.6-1jpp_5fc.x86_64 requires libgcj.so.6()(64bit) p6spy - 1.3-2jpp_3fc.x86_64 requires libgcj.so.6()(64bit) struts - 1.2.4-2jpp_3fc.x86_64 requires libgcj.so.6()(64bit) struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.x86_64 requires libgcj.so.6()(64bit) systemtap - 0.5-2.x86_64 requires libdw.so.1(ELFUTILS_0.116)(64bit) tomcat5 - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) tomcat5-admin-webapps - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) tomcat5-jasper - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) tomcat5-webapps - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) xalan-j2 - 2.6.0-3jpp_4fc.x86_64 requires libgcj.so.6()(64bit) xalan-j2-demo - 2.6.0-3jpp_4fc.x86_64 requires libgcj.so.6()(64bit) xalan-j2-xsltc - 2.6.0-3jpp_4fc.x86_64 requires libgcj.so.6()(64bit) From ilpettegolo at yahoo.it Wed Dec 14 09:00:14 2005 From: ilpettegolo at yahoo.it (Mario Pascucci) Date: Wed, 14 Dec 2005 10:00:14 +0100 Subject: rhn-applet replacement... In-Reply-To: <1134507992.25547.191.camel@dionysus.zoidtechnologies.com> References: <1134480376.8843.9.camel@defiant> <1134507992.25547.191.camel@dionysus.zoidtechnologies.com> Message-ID: <1134550814.3920.20.camel@defiant> Il giorno mar, 13/12/2005 alle 16.06 -0500, Jeff MacDonald ha scritto: > On Tue, 2005-12-13 at 14:26 +0100, Mario Pascucci wrote: > > I've installed Fedora Core 4, and I found that rhn-applet alert icon is > > not working at all. > > Playing with bash scripting, I've made a very simple script that checks > > via "sudoed" command 'yum check-update' for updates and display an icon > > on the Gnome panel "notification area" applet using Zenity. > > > > It's a very poor method, but it works... > > If someone is interested, I'm happy to share this very simple script. > > HTH > > > > yes, please post to the list with your script. Ok, it's here. There are two files, one is the script itself (fedupdatealert), and the other is the configuration file (fedupdatealert.conf). It needs: Zenity (from gnome-utils), sudo, yum and notification-area-applet. Place the script in the /usr/local/bin, or in the ~/bin if you have only one user, and the configuration file in the same directory. Add this line in "sudoers" file: ALL ALL=NOPASSWD: /usr/bin/yum check-update It's needed to run yum with root privileges and without asking a password. Without privileges, yum cannot download the xml from repositories and run entirely from cache, so the check isn't useful. I make the script running with the "Sessions" configuration utility of Gnome desktop. Open questions/Known problems: - a click to the icon closes zenity. The icon will appear in the next loop og the script. - when user exits from desktop session, the script is not terminated, and I don't know what method is the best way to check for this event. - the script uses a very "dirty" method to detect session ending: if zenity returns 255, it means that zenity cannot connect to X diplay (no user logged, or different user logged), and exits. The script at this moment is under test in my notebook, and it worked for two days without problems. Thanks. -- Mario 'Reliant' Pascucci http://ilpettegolo.altervista.org/ -------------- next part -------------- A non-text attachment was scrubbed... Name: fedupdatealert Type: application/x-shellscript Size: 2388 bytes Desc: not available URL: -------------- next part -------------- # configuration file Fedora update alert notification icon # default uses rhn-applet icons # icon for "ok" OKico="/usr/share/doc/rhn-applet-2.1.17/figs/applet/applet-okay-48.png" # icon for "updates available" UPDico="/usr/share/doc/rhn-applet-2.1.17/figs/applet/applet-critical-48.png" # icon for "troubles" WARNico="/usr/share/doc/rhn-applet-2.1.17/figs/applet/applet-error-48.png" # icon for "check in progress" WORKico="/usr/share/doc/rhn-applet-2.1.17/figs/applet/applet-busy-48.png" # interval between two checks (seconds) INTERVAL=3600 From jfrieben at freesurf.fr Wed Dec 14 08:55:29 2005 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Wed, 14 Dec 2005 09:55:29 +0100 (CET) Subject: Default cursor theme for FC5. In-Reply-To: <439FD56B.8040608@web.de> References: <439FD56B.8040608@web.de> Message-ID: <12238.194.94.224.254.1134550529.squirrel@arlette.freesurf.fr> I think the classic Bluecurve icon cursor them is much better anyway than this spinning blue thingy of FC5-rawhide. Its blue color is especially problematic on top of coloured backgrounds. The "jinmac" theme is the one already used by Ubuntu, I think. Quite ugly though. One should simply revert to the FC4 theme which is simple and good looking. From thomas at apestaart.org Wed Dec 14 10:39:43 2005 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Wed, 14 Dec 2005 11:39:43 +0100 Subject: gstreamer 0.10 In-Reply-To: <3adc77210512111221u409de288l622211bdc089adf0@mail.gmail.com> References: <1134100748.11873.9.camel@localhost.localdomain> <43999BEE.6030002@conversis.de> <1134143154.11873.55.camel@localhost.localdomain> <3adc77210512111221u409de288l622211bdc089adf0@mail.gmail.com> Message-ID: <1134556783.3026.63.camel@thomas.amantes> Hi, > Even plugins are divided into three parts. Good: well written plugins > without legal/lincensing issues. Bad: well written plugins with either > patent/licence problems. Ugly: ugly code. once cleaned up wil go into > good or bad depending on relevant issues. Almost correct. Ugly is the package containing good code but ugly licensing/legal issues, which could prompt distributors not to ship. Bad is what contains code that hasn't passed a QA check yet. See http://gstreamer.freedesktop.org/documentation/splitup.html for more explanation. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> "Don't worry, Joey, it's unisex." "Maybe you need sex, I just had some a couple of days ago !" "No, no, U-N-I-sex !" "Well, I ain't gonna say no to that !" <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From thomas at apestaart.org Wed Dec 14 10:47:07 2005 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Wed, 14 Dec 2005 11:47:07 +0100 Subject: gstreamer 0.10 In-Reply-To: <439CBBC0.2070201@conversis.de> References: <1134100748.11873.9.camel@localhost.localdomain> <43999BEE.6030002@conversis.de> <1134143154.11873.55.camel@localhost.localdomain> <3adc77210512111221u409de288l622211bdc089adf0@mail.gmail.com> <439CBBC0.2070201@conversis.de> Message-ID: <1134557227.3026.71.camel@thomas.amantes> On Mon, 2005-12-12 at 00:52 +0100, Dennis Jacobfeuerborn wrote: > Naheem Zaffar wrote: > > I did not think there would be a day fedora would shy away from the > > latest stuff. If there are problesm, well that is the point of rawhide > > and test releases. > > Right now the problem is that software that actually makes use of gstreamer > 0.10 seems to be hard to come by. Software that has support for 0.10 atm: - Flumotion (http://www.flumotion.net/) - totem (configure option in CVS HEAD) - jamboree (CVS HEAD) - pitivi (CVS HEAD) - Rhythmbox (CVS HEAD) - Banshee (HEAD) - bmpx (HEAD) Given that 0.10 has been out for nine days at this point, that's a pretty good start. releases of these are expected this month. > After giving up on Banshee I tried > Rhythmbox HEAD which kinda works but not really. Playing a file doesn't > work right away and I have to give the seekbar a little nudge to make it > start playing. Does this happen always ? Every type of file ? More info would help. > Unfortunately that's actually more than I get out of > Rhythmbox with gstreamer 0.8 (see > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174917 ). Hm, two things: a) a bug report on rhythmbox is probably better put into rhythmbox's bugzilla. b) the bug report is short on details. What version of GStreamer ? What types of files ? What audio sink ? What CPU ? ... Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> I'll take a quiet life a handshake of carbon monoxide <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From thomas at apestaart.org Wed Dec 14 10:48:11 2005 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Wed, 14 Dec 2005 11:48:11 +0100 Subject: gstreamer 0.10 In-Reply-To: <1134073170.12155.0.camel@gilboa-home-dev.localhost> References: <1134073170.12155.0.camel@gilboa-home-dev.localhost> Message-ID: <1134557292.3026.73.camel@thomas.amantes> Hi, > I sure hope so. > 0.8 has severe problems when using arts that are supposed to be fixed in > 0.10. not sure what makes you think this - unless you consider the arts plugin not being built anymore a fix. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> I looked up at Anna She turned back to look at me It's best to kill the ones that matter Render blind the ones that see <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From thomas at apestaart.org Wed Dec 14 10:53:36 2005 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Wed, 14 Dec 2005 11:53:36 +0100 Subject: gstreamer 0.10 In-Reply-To: <1134132779.20058.8.camel@krikkit.xn--kremla-iuad.se> References: <1134100748.11873.9.camel@localhost.localdomain> <1134132779.20058.8.camel@krikkit.xn--kremla-iuad.se> Message-ID: <1134557617.3026.78.camel@thomas.amantes> Hi, > On Thu, 2005-12-08 at 22:59 -0500, John (J5) Palmieri wrote: > > If a significant portion > > of core apps start depending on 0.10 then we can pull it in. > Totem and rhythmbox have got ports to 0.10 and will most definitely be > ready when Gnome 2.14 is released. Has there been a final "decision" on whether FC5 will ship with GNOME 2.14 ? > I also think it would be very good to have 'cause it's a major leap in > terms of videoperformance (and audio too, the Rhythmbox port is quit a > bit faster then the 0.8 version) also next gen programs like Diva (I > know you will not ship it, but 3rd party reps.) will require it. It's just a *lot* better at threadsafety in general. Combined with the patches GStreamer hackers have contributed to GLib 2.8 to make more of it threadsafe, it is a lot more solid. > Getting it into rawhide sooner than later could also mean great feedback > to the developers. True, and it would be much appreciated. Shipping e.g. totem in FC5test2 - even if from CVS - with the 0.10 backend now would anticipate correctly on the eventual situation when FC5 gets released, and would actually help us stabilize it if need be. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> Bye bye long day need to sleep so much ninety hours straight <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From gilboada at netvision.net.il Wed Dec 14 11:20:49 2005 From: gilboada at netvision.net.il (Gilboa Davara) Date: Wed, 14 Dec 2005 13:20:49 +0200 Subject: gstreamer 0.10 In-Reply-To: <1134557292.3026.73.camel@thomas.amantes> References: <1134073170.12155.0.camel@gilboa-home-dev.localhost> <1134557292.3026.73.camel@thomas.amantes> Message-ID: <1134559249.15561.18.camel@gilboa-work-dev> On Wed, 2005-12-14 at 11:48 +0100, Thomas Vander Stichele wrote: > Hi, > > > > I sure hope so. > > 0.8 has severe problems when using arts that are supposed to be fixed in > > 0.10. > > not sure what makes you think this - unless you consider the arts plugin > not being built anymore a fix. Ummm... this is bad. Without arts support, how can I concurrently use both arts applications (artsdsp OSS and/or KDE applications) and alsa applications (Amarok over gstreamer) without having lock problems? > > Thomas > Gilboa From rob at choralone.org Wed Dec 14 11:31:20 2005 From: rob at choralone.org (Rob Andrews) Date: Wed, 14 Dec 2005 11:31:20 +0000 Subject: gstreamer 0.10 In-Reply-To: <1134559249.15561.18.camel@gilboa-work-dev> References: <1134073170.12155.0.camel@gilboa-home-dev.localhost> <1134557292.3026.73.camel@thomas.amantes> <1134559249.15561.18.camel@gilboa-work-dev> Message-ID: <20051214113120.GA20794@testure.choralone.org> On 14-Dec-2005 11:20.49 (GMT), Gilboa Davara wrote: > Ummm... this is bad. > Without arts support, how can I concurrently use both arts applications > (artsdsp OSS and/or KDE applications) and alsa applications (Amarok over > gstreamer) without having lock problems? http://alsa.opensrc.org/index.php?page=DmixPlugin -- rob andrews rob at choralone.org From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Wed Dec 14 11:27:01 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Wed, 14 Dec 2005 12:27:01 +0100 Subject: gstreamer 0.10 In-Reply-To: <1134559249.15561.18.camel@gilboa-work-dev> References: <1134073170.12155.0.camel@gilboa-home-dev.localhost> <1134557292.3026.73.camel@thomas.amantes> <1134559249.15561.18.camel@gilboa-work-dev> Message-ID: <20051214122701.438c2e22@python2> Gilboa Davara wrote : > > > 0.8 has severe problems when using arts that are supposed to be fixed in > > > 0.10. > > > > not sure what makes you think this - unless you consider the arts plugin > > not being built anymore a fix. > > Ummm... this is bad. > Without arts support, how can I concurrently use both arts applications > (artsdsp OSS and/or KDE applications) and alsa applications (Amarok over > gstreamer) without having lock problems? By having the underlying ALSA configured to use dmix, as it is currently the default in FC (at least for most if not all cards)? Just a wild guess... Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.14-1.1644_FC4 Load : 3.22 1.86 1.68 From rob at choralone.org Wed Dec 14 11:35:35 2005 From: rob at choralone.org (Rob Andrews) Date: Wed, 14 Dec 2005 11:35:35 +0000 Subject: gstreamer 0.10 In-Reply-To: <20051214113120.GA20794@testure.choralone.org> References: <1134073170.12155.0.camel@gilboa-home-dev.localhost> <1134557292.3026.73.camel@thomas.amantes> <1134559249.15561.18.camel@gilboa-work-dev> <20051214113120.GA20794@testure.choralone.org> Message-ID: <20051214113535.GA20833@testure.choralone.org> On 14-Dec-2005 11:31.20 (GMT), Rob Andrews wrote: > > Ummm... this is bad. > > Without arts support, how can I concurrently use both arts applications > > (artsdsp OSS and/or KDE applications) and alsa applications (Amarok over > > gstreamer) without having lock problems? > http://alsa.opensrc.org/index.php?page=DmixPlugin Sorry, my reply was supposed to be more verbose but I'm running on autopilot this morning. dmix is an alsa helper for devices that don't support hardware mixing or have fixed-frequency codecs (e.g. the 48000Hz fixed-frequency Intel/VIA/SIS integrated audio devices). It downmixes and frequency scales as required. -- rob andrews rob at choralone.org From mailinglists at erwinrol.com Wed Dec 14 11:32:43 2005 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 14 Dec 2005 12:32:43 +0100 Subject: rawhide report: 20051214 changes In-Reply-To: <200512140830.jBE8UuHq028440@porkchop.devel.redhat.com> References: <200512140830.jBE8UuHq028440@porkchop.devel.redhat.com> Message-ID: <1134559963.9000.58.camel@xpc.home.erwinrol.com> Yum seems to be broken, when i do a update it "crashes" like; # yum update system-config-securitylevel-tui.x86_64 system-config-securitylevel.x86_64 system-config-language.noarch system-config-kickstart.noarch system-config-date.noarch subversion-perl.x86_64 subversion.x86_64 Loading "installonlyn" plugin Setting up Update Process Setting up repositories development 100% |=========================| 1.1 kB 00:00 freshrpms 100% |=========================| 951 B 00:00 extras-development 100% |=========================| 1.1 kB 00:00 Reading repository metadata in from local files Resolving Dependencies --> Populating transaction set with selected packages. Please wait. ---> Package system-config-securitylevel-tui.x86_64 0:1.6.12-1 set to be updated ---> Package system-config-kickstart.noarch 0:2.6.2-1 set to be updated ---> Package system-config-date.noarch 0:1.7.99.9-1 set to be updated ---> Package system-config-language.noarch 0:1.1.10-1.1 set to be updated ---> Package system-config-securitylevel.x86_64 0:1.6.12-1 set to be updated ---> Package subversion.x86_64 0:1.2.3-6 set to be updated ---> Package subversion-perl.x86_64 0:1.2.3-6 set to be updated --> Running transaction check --> Processing Dependency: subversion = 1.2.3-5 for package: mod_dav_svn 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 138, in main (result, resultmsgs) = base.buildTransaction() File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 370, in buildTransaction (rescode, restring) = self.resolveDeps() File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 254, in resolveDeps (checkdep, missing, conflict, errormsgs) = self._processReq(dep) File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 385, in _processReq requirementTuple, errormsgs) File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 518, in _requiringFromInstalled needpo = self.getInstalledPackageObject(needpkgtup) File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 1358, in getInstalledPackageObject hdrs = self.rpmdb.returnHeaderByTuple(pkgtup) File "/usr/lib/python2.4/site-packages/rpmUtils/__init__.py", line 220, in returnHeaderByTuple idxs = self.returnIndexByTuple(pkgtuple) File "/usr/lib/python2.4/site-packages/rpmUtils/__init__.py", line 228, in returnIndexByTuple return self.indexdict[pkgtuple] KeyError: ('subversion', 'x86_64', '0', '1.2.3', '6') It only seems to work if all dependencies are present on the commandline, in the example above it works when i add mod_dav_svn to the commandline. yum --version Loading "installonlyn" plugin 2.5.0 - Erwin > yum-2.5.0-1 > ----------- > * Tue Dec 13 2005 Jeremy Katz - 2.5.0-1 > - update to 2.5.0 > - add patch for traceback in #175647 From gilboada at netvision.net.il Wed Dec 14 11:36:46 2005 From: gilboada at netvision.net.il (Gilboa Davara) Date: Wed, 14 Dec 2005 13:36:46 +0200 Subject: gstreamer 0.10 In-Reply-To: <20051214113120.GA20794@testure.choralone.org> References: <1134073170.12155.0.camel@gilboa-home-dev.localhost> <1134557292.3026.73.camel@thomas.amantes> <1134559249.15561.18.camel@gilboa-work-dev> <20051214113120.GA20794@testure.choralone.org> Message-ID: <1134560206.15561.20.camel@gilboa-work-dev> On Wed, 2005-12-14 at 11:31 +0000, Rob Andrews wrote: > On 14-Dec-2005 11:20.49 (GMT), Gilboa Davara wrote: > > Ummm... this is bad. > > Without arts support, how can I concurrently use both arts applications > > (artsdsp OSS and/or KDE applications) and alsa applications (Amarok over > > gstreamer) without having lock problems? > > http://alsa.opensrc.org/index.php?page=DmixPlugin > > -- > rob andrews rob at choralone.org > Last time I tried dmix, it caused severe shuttering on my system. Guess I'll give it a try again. Thanks. Gilboa From gilboada at netvision.net.il Wed Dec 14 11:40:44 2005 From: gilboada at netvision.net.il (Gilboa Davara) Date: Wed, 14 Dec 2005 13:40:44 +0200 Subject: gstreamer 0.10 In-Reply-To: <20051214113535.GA20833@testure.choralone.org> References: <1134073170.12155.0.camel@gilboa-home-dev.localhost> <1134557292.3026.73.camel@thomas.amantes> <1134559249.15561.18.camel@gilboa-work-dev> <20051214113120.GA20794@testure.choralone.org> <20051214113535.GA20833@testure.choralone.org> Message-ID: <1134560444.15561.23.camel@gilboa-work-dev> On Wed, 2005-12-14 at 11:35 +0000, Rob Andrews wrote: > On 14-Dec-2005 11:31.20 (GMT), Rob Andrews wrote: > > > Ummm... this is bad. > > > Without arts support, how can I concurrently use both arts applications > > > (artsdsp OSS and/or KDE applications) and alsa applications (Amarok over > > > gstreamer) without having lock problems? > > http://alsa.opensrc.org/index.php?page=DmixPlugin > > Sorry, my reply was supposed to be more verbose but I'm running on > autopilot this morning. > > dmix is an alsa helper for devices that don't support hardware mixing or > have fixed-frequency codecs (e.g. the 48000Hz fixed-frequency > Intel/VIA/SIS integrated audio devices). It downmixes and frequency > scales as required. > > -- > rob andrews rob at choralone.org > OK. Being an idiot is fun. Guess this why I do it all the time. dmix works out of the box on my FC4 machine. Go figure. /me for a rock to hide under... Gilboa From m.f.h at web.de Wed Dec 14 11:44:17 2005 From: m.f.h at web.de (Marcus Hartig) Date: Wed, 14 Dec 2005 12:44:17 +0100 Subject: Default cursor theme for FC5. In-Reply-To: <12238.194.94.224.254.1134550529.squirrel@arlette.freesurf.fr> References: <439FD56B.8040608@web.de> <12238.194.94.224.254.1134550529.squirrel@arlette.freesurf.fr> Message-ID: <43A00591.9000804@web.de> Joachim Frieben wrote: > The "jinmac" theme is the one already used by Ubuntu, I think. > Quite ugly though. One should simply revert to the FC4 theme > which is simple and good looking. Ugly for you? Hm, that is the point why Fedora needs a little nice selection from maybe the artwork package: - bluecurve (small and big) - bluecurve inverse (small and big) - jimmac0 - lil-polar (highest rated on gnome-look) - big Tux Cursor (for the kids) And the most users with different tastes, blind people, different screen resolutions and notebook users are all happy. If there are no license problems to include them... ;) Marcus From paul at all-the-johnsons.co.uk Wed Dec 14 12:06:50 2005 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Wed, 14 Dec 2005 12:06:50 +0000 Subject: rawhide report: 20051214 changes In-Reply-To: <200512140830.jBE8UuHq028440@porkchop.devel.redhat.com> References: <200512140830.jBE8UuHq028440@porkchop.devel.redhat.com> Message-ID: <1134562011.29902.42.camel@T7.Linux> > kernel-2.6.14-1.1760_FC5 > ------------------------ x86_64 is reporting this as 1756_FC5 - is there a reason for this? I've done a yum clean all before the update. TTFN Paul -- "Religion is the opiate of the masses" - Karl Marx "Mmmmmm, mass opiates...." - Homer Simpson From mailinglists at erwinrol.com Wed Dec 14 12:08:40 2005 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 14 Dec 2005 13:08:40 +0100 Subject: rawhide report: 20051214 changes In-Reply-To: <1134559963.9000.58.camel@xpc.home.erwinrol.com> References: <200512140830.jBE8UuHq028440@porkchop.devel.redhat.com> <1134559963.9000.58.camel@xpc.home.erwinrol.com> Message-ID: <1134562121.9000.60.camel@xpc.home.erwinrol.com> After disabling a plugin in /etc/yum/pluginconf.d/installonlyn.conf it worked normal again. - Erwin On Wed, 2005-12-14 at 12:32 +0100, Erwin Rol wrote: > Yum seems to be broken, when i do a update it "crashes" like; > > # yum update system-config-securitylevel-tui.x86_64 system-config-securitylevel.x86_64 system-config-language.noarch system-config-kickstart.noarch system-config-date.noarch subversion-perl.x86_64 subversion.x86_64 > Loading "installonlyn" plugin > Setting up Update Process > Setting up repositories > development 100% |=========================| 1.1 kB 00:00 > freshrpms 100% |=========================| 951 B 00:00 > extras-development 100% |=========================| 1.1 kB 00:00 > Reading repository metadata in from local files > Resolving Dependencies > --> Populating transaction set with selected packages. Please wait. > ---> Package system-config-securitylevel-tui.x86_64 0:1.6.12-1 set to be updated > ---> Package system-config-kickstart.noarch 0:2.6.2-1 set to be updated > ---> Package system-config-date.noarch 0:1.7.99.9-1 set to be updated > ---> Package system-config-language.noarch 0:1.1.10-1.1 set to be updated > ---> Package system-config-securitylevel.x86_64 0:1.6.12-1 set to be updated > ---> Package subversion.x86_64 0:1.2.3-6 set to be updated > ---> Package subversion-perl.x86_64 0:1.2.3-6 set to be updated > --> Running transaction check > --> Processing Dependency: subversion = 1.2.3-5 for package: mod_dav_svn > 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 138, in main > (result, resultmsgs) = base.buildTransaction() > File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 370, in buildTransaction > (rescode, restring) = self.resolveDeps() > File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 254, in resolveDeps > (checkdep, missing, conflict, errormsgs) = self._processReq(dep) > File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 385, in _processReq > requirementTuple, errormsgs) > File "/usr/lib/python2.4/site-packages/yum/depsolve.py", line 518, in _requiringFromInstalled > needpo = self.getInstalledPackageObject(needpkgtup) > File "/usr/lib/python2.4/site-packages/yum/__init__.py", line 1358, in getInstalledPackageObject > hdrs = self.rpmdb.returnHeaderByTuple(pkgtup) > File "/usr/lib/python2.4/site-packages/rpmUtils/__init__.py", line 220, in returnHeaderByTuple > idxs = self.returnIndexByTuple(pkgtuple) > File "/usr/lib/python2.4/site-packages/rpmUtils/__init__.py", line 228, in returnIndexByTuple > return self.indexdict[pkgtuple] > KeyError: ('subversion', 'x86_64', '0', '1.2.3', '6') > > > It only seems to work if all dependencies are present on the > commandline, in the example above it works when i add mod_dav_svn to the > commandline. > > yum --version > Loading "installonlyn" plugin > 2.5.0 > > > - Erwin > > > yum-2.5.0-1 > > ----------- > > * Tue Dec 13 2005 Jeremy Katz - 2.5.0-1 > > - update to 2.5.0 > > - add patch for traceback in #175647 > > From dcbw at redhat.com Wed Dec 14 12:10:39 2005 From: dcbw at redhat.com (Dan Williams) Date: Wed, 14 Dec 2005 07:10:39 -0500 Subject: gstreamer 0.10 In-Reply-To: <20051214113535.GA20833@testure.choralone.org> References: <1134073170.12155.0.camel@gilboa-home-dev.localhost> <1134557292.3026.73.camel@thomas.amantes> <1134559249.15561.18.camel@gilboa-work-dev> <20051214113120.GA20794@testure.choralone.org> <20051214113535.GA20833@testure.choralone.org> Message-ID: <1134562240.2751.8.camel@localhost.localdomain> On Wed, 2005-12-14 at 11:35 +0000, Rob Andrews wrote: > On 14-Dec-2005 11:31.20 (GMT), Rob Andrews wrote: > > > Ummm... this is bad. > > > Without arts support, how can I concurrently use both arts applications > > > (artsdsp OSS and/or KDE applications) and alsa applications (Amarok over > > > gstreamer) without having lock problems? > > http://alsa.opensrc.org/index.php?page=DmixPlugin > > Sorry, my reply was supposed to be more verbose but I'm running on > autopilot this morning. > > dmix is an alsa helper for devices that don't support hardware mixing or > have fixed-frequency codecs (e.g. the 48000Hz fixed-frequency > Intel/VIA/SIS integrated audio devices). It downmixes and frequency > scales as required. Yeah, it does all that, but it's also the way you stop contention of the sound device[s]. You point _all_ programs that need to output sound at dmix, and then only dmix needs to talk directly to the sound hardware through alsa. This stops eg xmms from blocking helixplayer from blocking Flash in firefox, etc. This is what all the other OSs that actually have sound device arbitration do AFAIK. On Mac OS X, you _don't_ touch the hardware, you don't open /dev/dsp, period. You talk to CoreAudio (or Carbon's SoundManager), which handles mixing and resampling if required, and passes all audio to the device. Which is what we should be doing in Linux too. The audio situation without something like dmix arbitration is just horrific. Dan From rob at choralone.org Wed Dec 14 13:06:58 2005 From: rob at choralone.org (Rob Andrews) Date: Wed, 14 Dec 2005 13:06:58 +0000 Subject: gstreamer 0.10 In-Reply-To: <1134562240.2751.8.camel@localhost.localdomain> References: <1134073170.12155.0.camel@gilboa-home-dev.localhost> <1134557292.3026.73.camel@thomas.amantes> <1134559249.15561.18.camel@gilboa-work-dev> <20051214113120.GA20794@testure.choralone.org> <20051214113535.GA20833@testure.choralone.org> <1134562240.2751.8.camel@localhost.localdomain> Message-ID: <20051214130658.GA21614@testure.choralone.org> On 14-Dec-2005 12:10.39 (GMT), Dan Williams wrote: > > dmix is an alsa helper for devices that don't support hardware mixing or > > have fixed-frequency codecs (e.g. the 48000Hz fixed-frequency > > Intel/VIA/SIS integrated audio devices). It downmixes and frequency > > scales as required. > This is what all the other OSs that actually have sound device > arbitration do AFAIK. On Mac OS X, you _don't_ touch the hardware, you > don't open /dev/dsp, period. You talk to CoreAudio (or Carbon's > SoundManager), which handles mixing and resampling if required, and > passes all audio to the device. Which is what we should be doing in > Linux too. The audio situation without something like dmix arbitration > is just horrific. But does dmix downmix when using a card that does support hardware mixing, e.g. emu10k1? In that case it would just be burning cycles unnecessarily. Plus if dmix was pushing through a channel that had an EAX filter on it would apply it to all audio output. -- rob andrews rob at choralone.org From pzad at pobox.sk Wed Dec 14 13:07:17 2005 From: pzad at pobox.sk (Peter Zubaj) Date: Wed, 14 Dec 2005 14:07:17 +0100 Subject: gstreamer 0.10 Message-ID: >Od: Rob Andrews [mailto:rob at choralone.org] >On 14-Dec-2005 12:10.39 (GMT), Dan Williams wrote: >> > dmix is an alsa helper for devices that don't support hardware mixing or >> > have fixed-frequency codecs (e.g. the 48000Hz fixed-frequency >> > Intel/VIA/SIS integrated audio devices). It downmixes and frequency >> > scales as required. >> This is what all the other OSs that actually have sound device >> arbitration do AFAIK. On Mac OS X, you _don't_ touch the hardware, you >> don't open /dev/dsp, period. You talk to CoreAudio (or Carbon's >> SoundManager), which handles mixing and resampling if required, and >> passes all audio to the device. Which is what we should be doing in >> Linux too. The audio situation without something like dmix arbitration >> is just horrific. > >But does dmix downmix when using a card that does support hardware >mixing, e.g. emu10k1? In that case it would just be burning cycles >unnecessarily. dmix is not used on emu10k1 > >Plus if dmix was pushing through a channel that had an EAX filter on it >would apply it to all audio output. > There is no EAX on linux and emu10k1. Aktivujte si neobmedzenu mailovu schranku na www.pobox.sk! From davej at redhat.com Wed Dec 14 13:23:13 2005 From: davej at redhat.com (Dave Jones) Date: Wed, 14 Dec 2005 08:23:13 -0500 Subject: rawhide report: 20051214 changes In-Reply-To: <1134562011.29902.42.camel@T7.Linux> References: <200512140830.jBE8UuHq028440@porkchop.devel.redhat.com> <1134562011.29902.42.camel@T7.Linux> Message-ID: <20051214132313.GC3829@redhat.com> On Wed, Dec 14, 2005 at 12:06:50PM +0000, Paul F. Johnson wrote: > > kernel-2.6.14-1.1760_FC5 > > ------------------------ > > x86_64 is reporting this as 1756_FC5 - is there a reason for this? unsynced mirror perhaps ? Dave From mclasen at redhat.com Wed Dec 14 13:24:09 2005 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 14 Dec 2005 08:24:09 -0500 Subject: Default cursor theme for FC5. In-Reply-To: <43A00591.9000804@web.de> References: <439FD56B.8040608@web.de> <12238.194.94.224.254.1134550529.squirrel@arlette.freesurf.fr> <43A00591.9000804@web.de> Message-ID: <1134566649.2825.25.camel@golem.boston.redhat.com> On Wed, 2005-12-14 at 12:44 +0100, Marcus Hartig wrote: > Joachim Frieben wrote: > > > The "jinmac" theme is the one already used by Ubuntu, I think. > > Quite ugly though. One should simply revert to the FC4 theme > > which is simple and good looking. > > Ugly for you? Hm, that is the point why Fedora needs a little nice > selection from maybe the artwork package: > > - bluecurve (small and big) > - bluecurve inverse (small and big) > - jimmac0 > - lil-polar (highest rated on gnome-look) > - big Tux Cursor (for the kids) > > And the most users with different tastes, blind people, different screen > resolutions and notebook users are all happy. If there are no license > problems to include them... ;) > > Marcus > Now that we can change cursor themes in the mouse capplet, I think it would be a very nice idea to package some quality cursor themes for Extras. Matthias From rob at choralone.org Wed Dec 14 13:33:49 2005 From: rob at choralone.org (Rob Andrews) Date: Wed, 14 Dec 2005 13:33:49 +0000 Subject: gstreamer 0.10 In-Reply-To: References: Message-ID: <20051214133349.GA21839@testure.choralone.org> On 14-Dec-2005 13:07.17 (GMT), Peter Zubaj wrote: > > > passes all audio to the device. Which is what we should be doing in > > > Linux too. The audio situation without something like dmix arbitration > > > is just horrific. > > But does dmix downmix when using a card that does support hardware > > mixing, e.g. emu10k1? In that case it would just be burning cycles > > unnecessarily. > dmix is not used on emu10k1 No, it's not. But if we were forced to push everything through dmix as a layer of arbitration, then it would be used. > > Plus if dmix was pushing through a channel that had an EAX filter on it > > would apply it to all audio output. > There is no EAX on linux and emu10k1. EAX is a series of bytecode compiled modules that can be built with as10k1 and loaded onto the emu10k1 with the ld10k1 tool. See http://emu10k1.sourceforge.net/as10k1-manual/index.html and (discontinued here but I think it's been continued elsewhere) http://ld10k1.sourceforge.net/ pages for details. -- rob andrews rob at choralone.org From tmus at tmus.dk Wed Dec 14 13:30:51 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Wed, 14 Dec 2005 14:30:51 +0100 Subject: Default cursor theme for FC5. In-Reply-To: <1134566649.2825.25.camel@golem.boston.redhat.com> References: <439FD56B.8040608@web.de> <12238.194.94.224.254.1134550529.squirrel@arlette.freesurf.fr> <43A00591.9000804@web.de> <1134566649.2825.25.camel@golem.boston.redhat.com> Message-ID: Matthias Clasen wrote: > On Wed, 2005-12-14 at 12:44 +0100, Marcus Hartig wrote: >> Joachim Frieben wrote: >> >>> The "jinmac" theme is the one already used by Ubuntu, I think. >>> Quite ugly though. One should simply revert to the FC4 theme >>> which is simple and good looking. >> Ugly for you? Hm, that is the point why Fedora needs a little nice >> selection from maybe the artwork package: >> >> - bluecurve (small and big) >> - bluecurve inverse (small and big) >> - jimmac0 >> - lil-polar (highest rated on gnome-look) >> - big Tux Cursor (for the kids) >> >> And the most users with different tastes, blind people, different screen >> resolutions and notebook users are all happy. If there are no license >> problems to include them... ;) >> >> Marcus >> > > Now that we can change cursor themes in the mouse capplet, I think it > would be a very nice idea to package some quality cursor themes for > Extras. > > Matthias > By all means, make a decent one (like bluecurve) default and make a selection of others available in extras. Since we're trying to slim core down, adding several mouse themes may not be the way to go! (although they don't fill that much space) /Thomas From tmus at tmus.dk Wed Dec 14 13:43:04 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Wed, 14 Dec 2005 14:43:04 +0100 Subject: mirror synchronization flags? Message-ID: Hi Please correct me if I'm wrong, but as far as I know, the fedora tree has no built-in semantics for letting other mirrors (perhaps even clients) know if they are fully synced or in the middle of a mirroring operation. How about documenting a way to use some sort of semaphore (file) that can be checked to make sure that mirroring has finished? Mirrors, clients retrieving their data from a certain mirror could then check/wait for the mirror to finish or find another mirror in the meantime? The document could also share a few ideas on what to include/exclude for certain types of mirrors, whether (or when) local createrepo should be setup and such? Debian has something like this IIRC, and it makes the mirroring a lot less prone to errors. Less chance of unresolved dependencies due to half-synced mirror. Less chance of yum (as example) to fail because a package specified in the repodata does not exist, stuff like that? Was something like this an idea or would it just complicate things more than need be? /Thomas From skvidal at phy.duke.edu Wed Dec 14 14:17:38 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 14 Dec 2005 09:17:38 -0500 Subject: mirror synchronization flags? In-Reply-To: References: Message-ID: <1134569858.16389.21.camel@cutter> On Wed, 2005-12-14 at 14:43 +0100, Thomas M Steenholdt wrote: > Hi > > Please correct me if I'm wrong, but as far as I know, the fedora tree > has no built-in semantics for letting other mirrors (perhaps even > clients) know if they are fully synced or in the middle of a mirroring > operation. > > How about documenting a way to use some sort of semaphore (file) that > can be checked to make sure that mirroring has finished? Mirrors, > clients retrieving their data from a certain mirror could then > check/wait for the mirror to finish or find another mirror in the meantime? > The document could also share a few ideas on what to include/exclude for > certain types of mirrors, whether (or when) local createrepo should be > setup and such? 1. wrong list for this discussion - the mirrors discussion list is more appropriate 2. you'd need the mirrors to use a consistent script in order to ensure that the files were retrieved in a correct order such that the semaphore file was retrieved last. This has proved to be harder to get folks to do than you would expect. -sv From m.f.h at web.de Wed Dec 14 14:33:10 2005 From: m.f.h at web.de (Marcus Hartig) Date: Wed, 14 Dec 2005 15:33:10 +0100 Subject: Default cursor theme for FC5. In-Reply-To: References: <439FD56B.8040608@web.de> <12238.194.94.224.254.1134550529.squirrel@arlette.freesurf.fr> <43A00591.9000804@web.de> <1134566649.2825.25.camel@golem.boston.redhat.com> Message-ID: <43A02D26.5080800@web.de> Thomas M Steenholdt wrote: > By all means, make a decent one (like bluecurve) default and make a > selection of others available in extras. > > Since we're trying to slim core down, adding several mouse themes may > not be the way to go! (although they don't fill that much space) Yes, but the jimmac cursor for example is only 185kb here... When I look in other places: /lib/kbd/consolefonts (194 fonts) /lib/kbd/consolefonts/partialfonts) /lib/kbd/keymaps ... SYSFONT="latarcyrheb-sun16" ? +1000 translations I will never use in /usr/share/locales: du -h 230M Nothing against Spain, but why are cups translations in Spanish laying here around? Is really no other way possible, that every pkg installs all translations from Chinese to xyz? And many man-pages and others...nobody read them really, only the sys admins or for the important linux tools...There are really other bigger things to slim the Linux or Fedora system down, as a little nice cursor using every day. Marcus From m.f.h at web.de Wed Dec 14 15:18:24 2005 From: m.f.h at web.de (Marcus Hartig) Date: Wed, 14 Dec 2005 16:18:24 +0100 Subject: rawhide report: 20051214 changes In-Reply-To: <200512140830.jBE8UuHq028440@porkchop.devel.redhat.com> References: <200512140830.jBE8UuHq028440@porkchop.devel.redhat.com> Message-ID: <43A037C0.8000608@web.de> > udev-077-1 > ---------- > * Tue Dec 13 2005 Harald Hoyer - 077-1 > - version 077 > - patch to include udevstart2 in udevd and delay daemonize until queue is empty Hangs here with 98% used CPU, no soundcard found... /sbin/udevsend: connection refused /sbin/udevsend: connection refused Back to 076-1 and it runs again fine. Marcus From otaylor at redhat.com Wed Dec 14 15:25:39 2005 From: otaylor at redhat.com (Owen Taylor) Date: Wed, 14 Dec 2005 10:25:39 -0500 Subject: pango multilib In-Reply-To: <1134468074.2905.24.camel@locolhost.localdomain> References: <1134468074.2905.24.camel@locolhost.localdomain> Message-ID: <1134573939.3166.16.camel@huygens> On Tue, 2005-12-13 at 02:01 -0800, Michael A. Peters wrote: > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175510 > Ignore the patch I added - it's not the right thing to do. > > Fedora ships two builds of pango - one for 32-bit and one for 64-bit > This makes sense because 64-bit systems are likely to want both versions > installed (assuming 32-bit install of Firefox, needed for 32-bit > plugins, will want 32-bit pango - I don't know but that makes sense) > > It seems to me though that other than the pango.modules file, there is a > conflict with the configuration files. > > It looks both 32 and 64 will want to use /etc/pango/pangorc (if it > exists) and both will want to use ~/.pangorc (if it exists) and both > will want to use the environmental variable PANGO_RC_FILE (if it is set) > > Unfortunately, those can only be correct for one or other - not both. I don't think there really are any legitimate reasons to set *anything* in the Pango RC file, much less set things differently for 32 and 64 bits. > My idea - for 64-bit builds, patch it to use > /etc/pango/pangorc64 ~/.pango64 and PANGO64_RC_FILE > update the pango-querymodules.1 man page for 64-bit to reflect that, and > change its name to pango-querymodules-64.1 (since pango-querymodules is > changed to pango-querymodules-64 already) The rc file isn't just pango-querymodules (conceptually; it isn't used for much at all right now.) So, this scheme takes the need for separate module directories for the two copies of the library and spreads it into other parts of Pango. > I have a patch on my system that does that, but w/o a 64-bit system I > can't test it. > > -=- > Currently - Fedora uses an arch specific place for the pango.modules > file. IE - /etc/pango/i386-redhat-linux-gnu/pango.modules > > I would suggest changing that back to > /etc/pango/pango.modules > > and for the 64bit build - use > /etc/pango/pango64.modules > > The rename of pango-querymodules to pango-querymodules-32 should be > undone imho. > > -=- > The result would be - 32-bit is like upstream intends it, with where the > files are located etc. > > The 64-bit would have config files at > > /etc/pango/pango64.modules /etc/pango/pangorc64 > ~/.pangorc64 /usr/bin/pango-querymodules-64 /usr/man/man1/pango-querymodules-64.1 > > No file conflicts, they could be installed side by side - and the > current scenario where the same (optional) but incompatible config files > are used by 32 and 64 would be resolved. > > Simplifying the pango.modules path to not have the host stuff in it > would also make it easier to script rpm scriptlets that need to run > pango-querymodules to regenerate the pango.modules file. > > -=- > Thoughts on this? Are there other apps that would break by changing the > pangorc name for 64-bit? I kind of doubt it because they are optional, > and other apps should be getting that info from pango. Your scheme might be a bit better than what we have currently, but it isn't a lot better (IMO), and I don't think it's worth a lot of pain and churn to switch to it. http://bugzilla.gnome.org/show_bug.cgi?id=129534 has a link to a detailed plan a wrote up for how I wanted to do it upstreams. > -=- > Where this is needed: > > http://mpeters.us/silgraphite/ > > It's a library and a set of pango modules, and they need to be seen by > pango in a specific order (the pango base modules are suppose to be > first in the pango ModulePath) > > To properly package the pango wrapper, it needs to be able to add the > path to its modules to Pango's ModulesPath - and that is broken right > now because the config files where that is set would set for both 32 and > 64 bit pango. I think trying to control module order is inherently fragile; you are going to have some horrible %post that tries to create and/or edit a pangorc file and that's going to be very unstable. What I suggested to Daniel at GUADEC was to delete all the { PANGO_SCRIPT_ARMENIAN, "*" }, and so forth out of basic-fc.c and leave just { PANGO_SCRIPT_COMMON, "" } That shouldn't have any affect on choice of the basic modules unless the graphite module is installed, and then it will always prefer the graphite module (If the graphite module lists itself as { PANGO_SCRIPT_COMMON, "*" }) This doesn't encapsulate some of the tricky font-choice issues, but ordering wouldn't help there either. There's no way by controlling ordering that you can win over arabic-fc.c when there is a Silf table and not when there is a GSUB table. (Just added the same text as a comment on http://bugzilla.gnome.org/show_bug.cgi?id=323661) Regards, Owen -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From tmus at tmus.dk Wed Dec 14 16:44:42 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Wed, 14 Dec 2005 17:44:42 +0100 Subject: Default cursor theme for FC5. In-Reply-To: <43A02D26.5080800@web.de> References: <439FD56B.8040608@web.de> <12238.194.94.224.254.1134550529.squirrel@arlette.freesurf.fr> <43A00591.9000804@web.de> <1134566649.2825.25.camel@golem.boston.redhat.com> <43A02D26.5080800@web.de> Message-ID: Marcus Hartig wrote: > Thomas M Steenholdt wrote: > >> By all means, make a decent one (like bluecurve) default and make a >> selection of others available in extras. >> >> Since we're trying to slim core down, adding several mouse themes may >> not be the way to go! (although they don't fill that much space) > > Yes, but the jimmac cursor for example is only 185kb here... > > When I look in other places: > /lib/kbd/consolefonts (194 fonts) > /lib/kbd/consolefonts/partialfonts) > /lib/kbd/keymaps > ... > SYSFONT="latarcyrheb-sun16" ? > > +1000 translations I will never use in /usr/share/locales: du -h > 230M > > Nothing against Spain, but why are cups translations in Spanish laying > here around? Is really no other way possible, that every pkg installs > all translations from Chinese to xyz? > > And many man-pages and others...nobody read them really, only the sys > admins or for the important linux tools...There are really other bigger > things to slim the Linux or Fedora system down, as a little nice cursor > using every day. > > Marcus > I agree that the jimmac theme is the way to go - but thats an oppinion - and others may (and will) disagree. As for all the other stuff to remove from the distro - that's a different thread and also a work in progress. I can't remember what was decided with regards to languages. I don't think you should get all languages installed unless you do an everything install or something, but i may be wrong. /Thomas From katzj at redhat.com Wed Dec 14 17:01:14 2005 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 14 Dec 2005 12:01:14 -0500 Subject: rawhide report: 20051214 changes In-Reply-To: <1134562121.9000.60.camel@xpc.home.erwinrol.com> References: <200512140830.jBE8UuHq028440@porkchop.devel.redhat.com> <1134559963.9000.58.camel@xpc.home.erwinrol.com> <1134562121.9000.60.camel@xpc.home.erwinrol.com> Message-ID: <1134579674.2708.17.camel@bree.local.net> On Wed, 2005-12-14 at 13:08 +0100, Erwin Rol wrote: > After disabling a plugin in /etc/yum/pluginconf.d/installonlyn.conf it > worked normal again. Yeah, I committed something I didn't mean to. Oops, will be fixed tomorrow. Although there's something else odd going on that I want to figure out before I actually do the build... That's for after lunch though :) Jeremy From fedora-devel-list at cygnusx-1.org Wed Dec 14 17:03:00 2005 From: fedora-devel-list at cygnusx-1.org (Nathan Grennan) Date: Wed, 14 Dec 2005 09:03:00 -0800 Subject: kernel-2.6.14-1.1653_FC4.netdev.6? Message-ID: <43A05044.7060803@cygnusx-1.org> I am interested in moving to kernel-2.6.14-1.1653_FC4, and I am curious when kernel-2.6.14-1.1653_FC4.netdev.6 will be out. On a side note I seem to have found another bug in sky2. I have no error messages or signs of why, but I found I could no longer ping other computers on the network via that interface. I also tested it, and they couldn't ping it. I first noticed the problem when trying to go to a web server on another machine via that interface and it couldn't connect. I checked the link status with ethtool and mii-tool. Both reported the link was good. I also tried resetting the switch, but no results. Finally I rebooted the computer and it worked again. It so far hasn't failed again. Any suggestions of what I can do next time to get some useful debugging information that might help track down the problem? From dhollis at davehollis.com Wed Dec 14 17:38:09 2005 From: dhollis at davehollis.com (David Hollis) Date: Wed, 14 Dec 2005 12:38:09 -0500 Subject: rawhide java still broken In-Reply-To: <439FB60E.7010107@insitesinc.com> References: <1134519189.29837.16.camel@yoda.loki.me> <439FB60E.7010107@insitesinc.com> Message-ID: <1134581889.18673.32.camel@dhollis-lnx.sunera.com> On Wed, 2005-12-14 at 00:05 -0600, Michael Favia wrote: > Jesse Keating wrote: > > I made a lot of headway, but not complete. Tomorrow's rawhide java > > stuff will still be broken. Sorry for the delay on this folks. > > Thank you for the heads up. An ounce of prevention saves a lot of > explanation to the people who think it is a unique problem to them. -mf > Amen to that. I was starting to think that my java stuffs were totally hosed, though I did find a lot of issues with multiple versions of various packages installed. It looks like a lot of the %postun scripts bombed out for various reasons leaving me with duplicate entries in the RPM database. I think I remember that rebuild-security-providers went missing at one point and that seemed to hose some stuff up. But it's looking better now. Hopefully in the next day or so, I'll be able to get everything updated once again. -- David Hollis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From wcooley at nakedape.cc Wed Dec 14 17:47:07 2005 From: wcooley at nakedape.cc (Wil Cooley) Date: Wed, 14 Dec 2005 09:47:07 -0800 Subject: funny user moment (and perhaps a bug) In-Reply-To: References: Message-ID: <1134582427.30388.4.camel@willow.odshp.com> On Tue, 2005-12-13 at 17:42 -0500, Jack Tanner wrote: > There were two unexpected things in this tale: first, the "remote" Gnome > session shouldn't have gotten a CD Player (if only because I didn't try > to forward audio in my NX settings, for one, but there are also probably > security considerations about console owners and such). Second, the > "local" CD Player should've been in synch with what was going on with > the CD (e.g., track changes were not reflected). I've seen this kind of thing too on FC4--I've plugged in my digital camera via USB and both the console and an X terminal have been got the "Import Photos" pop-up. Wil -- Wil Cooley Naked Ape Consulting, Ltd -------------- 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 michael.favia at insitesinc.com Wed Dec 14 18:17:43 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Wed, 14 Dec 2005 12:17:43 -0600 Subject: Default cursor theme for FC5. In-Reply-To: <12238.194.94.224.254.1134550529.squirrel@arlette.freesurf.fr> References: <439FD56B.8040608@web.de> <12238.194.94.224.254.1134550529.squirrel@arlette.freesurf.fr> Message-ID: <43A061C7.5080604@insitesinc.com> Joachim Frieben wrote: > I think the classic Bluecurve icon cursor them is much better > anyway than this spinning blue thingy of FC5-rawhide. Its blue > color is especially problematic on top of coloured backgrounds. > The "jinmac" theme is the one already used by Ubuntu, I think. > Quite ugly though. One should simply revert to the FC4 theme > which is simple and good looking. Maybe it's a sign of poor pedigree but i actually prefer the spinning blue dots when i wait and wait and wait on gnome. :). -mf From thomas at apestaart.org Wed Dec 14 18:16:27 2005 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Wed, 14 Dec 2005 19:16:27 +0100 Subject: gstreamer 0.10 In-Reply-To: <1134562240.2751.8.camel@localhost.localdomain> References: <1134073170.12155.0.camel@gilboa-home-dev.localhost> <1134557292.3026.73.camel@thomas.amantes> <1134559249.15561.18.camel@gilboa-work-dev> <20051214113120.GA20794@testure.choralone.org> <20051214113535.GA20833@testure.choralone.org> <1134562240.2751.8.camel@localhost.localdomain> Message-ID: <1134584187.3429.3.camel@thomas.amantes> Hi, > This is what all the other OSs that actually have sound device > arbitration do AFAIK. On Mac OS X, you _don't_ touch the hardware, you > don't open /dev/dsp, period. You talk to CoreAudio (or Carbon's > SoundManager), which handles mixing and resampling if required, and > passes all audio to the device. Which is what we should be doing in > Linux too. The audio situation without something like dmix arbitration > is just horrific. I agree with the theory; sadly, dmix still does not work reliably on some popular chips. ac97 users still see any of a) lockups, no CPU use b) lockups, 100% CPU use c) frames of audio being played in random order, sounds like a skipping CD player. ALSA would benefit from a distro actually employing one of them and giving them the mission to get it to Work On Every Card. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> Don't change your name keep it the same for fear I may lose you again I know you won't it's just that I am unorganized and I want to find you when Something good happens <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From fedora at leemhuis.info Wed Dec 14 18:43:55 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 14 Dec 2005 19:43:55 +0100 Subject: gstreamer 0.10 In-Reply-To: <1134557617.3026.78.camel@thomas.amantes> References: <1134100748.11873.9.camel@localhost.localdomain> <1134132779.20058.8.camel@krikkit.xn--kremla-iuad.se> <1134557617.3026.78.camel@thomas.amantes> Message-ID: <1134585835.2805.3.camel@localhost.localdomain> Am Mittwoch, den 14.12.2005, 11:53 +0100 schrieb Thomas Vander Stichele: > > On Thu, 2005-12-08 at 22:59 -0500, John (J5) Palmieri wrote: > > Totem and rhythmbox have got ports to 0.10 and will most definitely be > > ready when Gnome 2.14 is released. > Has there been a final "decision" on whether FC5 will ship with GNOME > 2.14 ? Well, I've not heard of an final "decision" -- but rawhide has a lot of gnome related packages with version 2.13.* (gnome-desktop for example). So we either have to use epochs to get back to 2.12 (not likely) or 2.14 is on the roadmap... CU thl From dishkuvek at dclam.com Wed Dec 14 19:01:34 2005 From: dishkuvek at dclam.com (Dick Dishkuvek) Date: Wed, 14 Dec 2005 14:01:34 -0500 Subject: Default cursor theme for FC5. In-Reply-To: <12238.194.94.224.254.1134550529.squirrel@arlette.freesurf.fr> References: <439FD56B.8040608@web.de> <12238.194.94.224.254.1134550529.squirrel@arlette.freesurf.fr> Message-ID: <1134586894.7799.7.camel@orange.milkhost.com> Joachim Frieben wrote: > I think the classic Bluecurve icon cursor them is much better > anyway than this spinning blue thingy of FC5-rawhide. I agree. The spinning blue thing is a distraction, it also makes the cursor take up too much area, cursors should be a little smaller, at least by default. There was a comment earlier about the FC4 cursors "busy" animated hour glass being too busy. This may be true, but it is certainly less busy than the blue spinning thing. I like both Bluecurve (FC4) and jimmac cursors. I don't see anything wrong with keeping the FC4 cursors. They are certainly the two best cursor themes out there, at least, in my opinion. From andda347 at student.liu.se Wed Dec 14 19:04:40 2005 From: andda347 at student.liu.se (David Andersson) Date: Wed, 14 Dec 2005 20:04:40 +0100 Subject: gstreamer 0.10 In-Reply-To: <1134585835.2805.3.camel@localhost.localdomain> References: <1134100748.11873.9.camel@localhost.localdomain> <1134132779.20058.8.camel@krikkit.xn--kremla-iuad.se> <1134557617.3026.78.camel@thomas.amantes> <1134585835.2805.3.camel@localhost.localdomain> Message-ID: <1134587081.20058.11.camel@krikkit.xn--kremla-iuad.se> On Wed, 2005-12-14 at 19:43 +0100, Thorsten Leemhuis wrote: > Am Mittwoch, den 14.12.2005, 11:53 +0100 schrieb Thomas Vander Stichele: > > > > On Thu, 2005-12-08 at 22:59 -0500, John (J5) Palmieri wrote: > > > Totem and rhythmbox have got ports to 0.10 and will most definitely be > > > ready when Gnome 2.14 is released. > > Has there been a final "decision" on whether FC5 will ship with GNOME > > 2.14 ? > > Well, I've not heard of an final "decision" -- but rawhide has a lot of > gnome related packages with version 2.13.* (gnome-desktop for example). > So we either have to use epochs to get back to 2.12 (not likely) or 2.14 > is on the roadmap... 2.14 is the plan http://fedoraproject.org/wiki/FC5Future -------------- 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 Dec 14 19:43:58 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Wed, 14 Dec 2005 20:43:58 +0100 Subject: gstreamer 0.10 In-Reply-To: <1134587081.20058.11.camel@krikkit.xn--kremla-iuad.se> References: <1134100748.11873.9.camel@localhost.localdomain> <1134132779.20058.8.camel@krikkit.xn--kremla-iuad.se> <1134557617.3026.78.camel@thomas.amantes> <1134585835.2805.3.camel@localhost.localdomain> <1134587081.20058.11.camel@krikkit.xn--kremla-iuad.se> Message-ID: <1134589438.2805.7.camel@localhost.localdomain> Am Mittwoch, den 14.12.2005, 20:04 +0100 schrieb David Andersson: > On Wed, 2005-12-14 at 19:43 +0100, Thorsten Leemhuis wrote: > > Am Mittwoch, den 14.12.2005, 11:53 +0100 schrieb Thomas Vander Stichele: > > > > > > On Thu, 2005-12-08 at 22:59 -0500, John (J5) Palmieri wrote: > > > > Totem and rhythmbox have got ports to 0.10 and will most definitely be > > > > ready when Gnome 2.14 is released. > > > Has there been a final "decision" on whether FC5 will ship with GNOME > > > 2.14 ? > > > > Well, I've not heard of an final "decision" -- but rawhide has a lot of > > gnome related packages with version 2.13.* (gnome-desktop for example). > > So we either have to use epochs to get back to 2.12 (not likely) or 2.14 > > is on the roadmap... > 2.14 is the plan http://fedoraproject.org/wiki/FC5Future Heck, that was me who added it there. But is still would say that I've not really heard a "official decision" ;-) CU thl -- Thorsten Leemhuis From dishkuvek at dclam.com Wed Dec 14 20:07:07 2005 From: dishkuvek at dclam.com (Dick Dishkuvek) Date: Wed, 14 Dec 2005 15:07:07 -0500 Subject: Default cursor theme for FC5. In-Reply-To: <1134586894.7799.7.camel@orange.milkhost.com> References: <439FD56B.8040608@web.de> <12238.194.94.224.254.1134550529.squirrel@arlette.freesurf.fr> <1134586894.7799.7.camel@orange.milkhost.com> Message-ID: <1134590827.12131.2.camel@orange.milkhost.com> So is known if the method for setting the cursor has changed? And if so, does anyone know the new method? There were talks of it possibly being in gconf settings, however, I've not been able to find anything. The normal way of putting an index.theme in ~/.icons/default is no longer working. From mclasen at redhat.com Wed Dec 14 20:15:55 2005 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 14 Dec 2005 15:15:55 -0500 Subject: Default cursor theme for FC5. In-Reply-To: <1134590827.12131.2.camel@orange.milkhost.com> References: <439FD56B.8040608@web.de> <12238.194.94.224.254.1134550529.squirrel@arlette.freesurf.fr> <1134586894.7799.7.camel@orange.milkhost.com> <1134590827.12131.2.camel@orange.milkhost.com> Message-ID: <1134591355.2761.3.camel@golem.boston.redhat.com> On Wed, 2005-12-14 at 15:07 -0500, Dick Dishkuvek wrote: > So is known if the method for setting the cursor has changed? And if > so, does anyone know the new method? There were talks of it possibly > being in gconf settings, however, I've not been able to find anything. > The normal way of putting an index.theme in ~/.icons/default is no > longer working. > GTK+ 2.8 picks up the X settings Gtk/CursorThemeName and Gtk/CursorThemeSize. These are being set by gnome-settings-daemon from the gconf keys /desktop/gnome/peripherals/mouse/cursor_theme and /desktop/gnome/peripherals/mouse/cursor_size. These can conveniently be tweaked using the mouse capplet. Matthias From tmus at tmus.dk Wed Dec 14 20:29:40 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Wed, 14 Dec 2005 21:29:40 +0100 Subject: mirror synchronization flags? In-Reply-To: <1134569858.16389.21.camel@cutter> References: <1134569858.16389.21.camel@cutter> Message-ID: seth vidal wrote: > 1. wrong list for this discussion - the mirrors discussion list is more > appropriate > 2. you'd need the mirrors to use a consistent script in order to ensure > that the files were retrieved in a correct order such that the semaphore > file was retrieved last. This has proved to be harder to get folks to do > than you would expect. 1. okay - i've been looking for the mirrors discussion list and can't seem to find it - any chance somebody could post a link os something? 2. I can't imagine this would be a problem for the official mirrors? I believe it's a matter of finding a solution (simple protocol if you will) that allows the mirrors to provide an even better service without too much fuss. It could also be a great way for a central (fedoraproject.org or something) status page that could easily poll the official mirrors for status and such. /Thomas From mpeters at mac.com Wed Dec 14 21:16:18 2005 From: mpeters at mac.com (Michael A. Peters) Date: Wed, 14 Dec 2005 13:16:18 -0800 Subject: pango multilib In-Reply-To: <1134573939.3166.16.camel@huygens> References: <1134468074.2905.24.camel@locolhost.localdomain> <1134573939.3166.16.camel@huygens> Message-ID: <1134594978.2776.11.camel@locolhost.localdomain> On Wed, 2005-12-14 at 10:25 -0500, Owen Taylor wrote: *snip* > > I don't think there really are any legitimate reasons to set *anything* > in the Pango RC file, much less set things differently for 32 and 64 > bits. OK. I'm not familiar with the goals of the pango project etc. but you clearly are, so then I need to assume that you are correct. The reason why they might need to be different in my mind is for the difference in path location of modules depending upon arch - namely /usr/lib vs /usr/lib64 Currently - if you set /etc/pangorc or ~/.pangorc and set a ModulesPath in it - unless I'm misunderstanding, 64 and 32 bit pango would both try to use it which would cause a problem. gnome bugzilla 129540 which you references looks like it addresses that issue, so I added myself to that cc list and will wait to see what comes from it. > > Your scheme might be a bit better than what we have currently, but it > isn't a lot better (IMO), and I don't think it's worth a lot of pain and > churn to switch to it. OK. What I'll do with the rpm packaging for the graphite pango wrapper then is do absolutely nothing in the %post scriptlets and put in a README.fedora that tells the user how to set it up in Fedora if they want to use the modules. From dsteven at bigpond.net.au Wed Dec 14 22:24:34 2005 From: dsteven at bigpond.net.au (Darren Steven) Date: Thu, 15 Dec 2005 09:24:34 +1100 (EST) Subject: funny user moment (and perhaps a bug) In-Reply-To: <1134582427.30388.4.camel@willow.odshp.com> References: <1134582427.30388.4.camel@willow.odshp.com> Message-ID: <12349.202.12.233.21.1134599074.squirrel@server.twofifty.bpa.nu> Hi, Just one question about this thread. Are local and remote the same user? If so, won't there be some reuse of the daemons etc that handle dbus interaction etc. I know with kde that it is a bit scary running 2x sessions as the same user. Things don't always behave. Not sure about gnome Just a though. Darren Steven > On Tue, 2005-12-13 at 17:42 -0500, Jack Tanner wrote: > >> There were two unexpected things in this tale: first, the "remote" Gnome >> session shouldn't have gotten a CD Player (if only because I didn't try >> to forward audio in my NX settings, for one, but there are also probably >> security considerations about console owners and such). Second, the >> "local" CD Player should've been in synch with what was going on with >> the CD (e.g., track changes were not reflected). > > I've seen this kind of thing too on FC4--I've plugged in my digital > camera via USB and both the console and an X terminal have been got the > "Import Photos" pop-up. > > Wil > -- > Wil Cooley > Naked Ape Consulting, Ltd > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From warren at togami.com Wed Dec 14 23:56:42 2005 From: warren at togami.com (Warren Togami) Date: Wed, 14 Dec 2005 18:56:42 -0500 Subject: gstreamer 0.10 In-Reply-To: <1134585835.2805.3.camel@localhost.localdomain> References: <1134100748.11873.9.camel@localhost.localdomain> <1134132779.20058.8.camel@krikkit.xn--kremla-iuad.se> <1134557617.3026.78.camel@thomas.amantes> <1134585835.2805.3.camel@localhost.localdomain> Message-ID: <43A0B13A.1040101@togami.com> Thorsten Leemhuis wrote: > Am Mittwoch, den 14.12.2005, 11:53 +0100 schrieb Thomas Vander Stichele: > >>> On Thu, 2005-12-08 at 22:59 -0500, John (J5) Palmieri wrote: >>> Totem and rhythmbox have got ports to 0.10 and will most definitely be >>> ready when Gnome 2.14 is released. >> Has there been a final "decision" on whether FC5 will ship with GNOME >> 2.14 ? > > Well, I've not heard of an final "decision" -- but rawhide has a lot of > gnome related packages with version 2.13.* (gnome-desktop for example). > So we either have to use epochs to get back to 2.12 (not likely) or 2.14 > is on the roadmap... > > CU > thl > We will likely have 2.14 final, or maybe a near final release candidate of 2.14. Don't worry, it will be good. Warren Togami wtogami at redhat.com From seandarcy2 at gmail.com Thu Dec 15 00:27:00 2005 From: seandarcy2 at gmail.com (sean) Date: Wed, 14 Dec 2005 19:27:00 -0500 Subject: unknown filesystem type 'nfs' ??? Message-ID: Updated to today's rawhide: mount /mnt/gateway mount: unknown filesystem type 'nfs' From /etc/fstab: gateway:/ /mnt/gateway nfs noauto,defaults service nfs restart Shutting down NFS mountd: [ OK ] Shutting down NFS daemon: [ OK ] Shutting down NFS quotas: [ OK ] Shutting down NFS services: [ OK ] Starting NFS services: [ OK ] Starting NFS quotas: [ OK ] Starting NFS daemon: [ OK ] Starting NFS mountd: [ OK ] Used to work about a week ago. Some new configuration I need to set up? sean From dominik at greysector.net Thu Dec 15 00:51:52 2005 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 15 Dec 2005 01:51:52 +0100 Subject: kernel-2.6.14-1.1653_FC4.netdev.6? In-Reply-To: <43A05044.7060803@cygnusx-1.org> References: <43A05044.7060803@cygnusx-1.org> Message-ID: <20051215005152.GF26108@rathann.pekin.waw.pl> On Wednesday, 14 December 2005 at 18:03, Nathan Grennan wrote: > I am interested in moving to kernel-2.6.14-1.1653_FC4, and I am > curious when kernel-2.6.14-1.1653_FC4.netdev.6 will be out. Me too. I'm interested in updated ipw2200 driver in particular. Regards, R. -- APT/YUM RPM repository for Fedora Core http://rpm.greysector.net/ mpg321, xmp, faad2, lame, mad, *mplayer*, rdesktop, tin, xvid, mks, mutt "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From linville at redhat.com Thu Dec 15 01:08:03 2005 From: linville at redhat.com (John W. Linville) Date: Wed, 14 Dec 2005 20:08:03 -0500 Subject: kernel-2.6.14-1.1653_FC4.netdev.6? In-Reply-To: <20051215005152.GF26108@rathann.pekin.waw.pl> References: <43A05044.7060803@cygnusx-1.org> <20051215005152.GF26108@rathann.pekin.waw.pl> Message-ID: <20051215010803.GE9801@redhat.com> On Thu, Dec 15, 2005 at 01:51:52AM +0100, Dominik 'Rathann' Mierzejewski wrote: > On Wednesday, 14 December 2005 at 18:03, Nathan Grennan wrote: > > I am interested in moving to kernel-2.6.14-1.1653_FC4, and I am > > curious when kernel-2.6.14-1.1653_FC4.netdev.6 will be out. > > Me too. I'm interested in updated ipw2200 driver in particular. Workin' on it... John -- John W. Linville linville at redhat.com From notting at redhat.com Thu Dec 15 03:18:22 2005 From: notting at redhat.com (Bill Nottingham) Date: Wed, 14 Dec 2005 22:18:22 -0500 Subject: libusual interface [was Re: libusual and ub] In-Reply-To: <20051029193544.096d400e.zaitcev@redhat.com> References: <20051029193544.096d400e.zaitcev@redhat.com> Message-ID: <20051215031822.GA12020@devserv.devel.redhat.com> Pete Zaitcev (zaitcev at redhat.com) said: > Hi, Dave, Jeremy, and others: > > I think now may be the time to enable ub in Rawhide and see if it sticks. > The problem it is trying to address is to have fewer oopses and/or lockups > related to the usb-storage. I have to say, I do not see all that many > these days, but when they do happen, it always happens as if on purpose > to break our schedule. > > Since ub does not support all storage devices, and never will, I developed > a way for it to coexist with usb-storage. A patch called "libusual" > provides the necessary routing. It is attached at the bottom of this > message, and I think is necessary if we are to have ub at all. Coming in late to the party (as usual), I'd have to say that, outside of any concerns about ub or usb-storage, I don't think libusual is the right interface. 1) It breaks all 'normal' probing for devices, as the device tables are removed from the module. You have to hardcode one module or the other if you're running in an environment where the modules aren't in 'normal' locations 2) It circumvents the normal hotplug mechanisms... while you're still getting events to userspace about the USB device add, the kernel is (effectively) handling the event behind your back. 3) If you want to change which one you use, since libusual is built-in, you have to reboot. This seems to be sort of a non-starter. I'd rather have the ids in the module as normal, and either: a) we blacklist one of the drivers b) we don't build one of the drivers c) we turn off automatic binding, and use the bind/unbind features to handle it Bill From ggw at wolves.durham.nc.us Thu Dec 15 04:37:02 2005 From: ggw at wolves.durham.nc.us (G.Wolfe Woodbury) Date: Wed, 14 Dec 2005 23:37:02 -0500 Subject: Nit-picking - GNOME "Desktop" menu? Message-ID: <20051215043702.GA3211@wolves.durham.nc.us> I thought I saw the "Desktop" menu change to "System" but now it's back at "Desktop"? Just curious. -- G.Wolfe Woodbury `- -' RHCT U The Line Eater is a boojum! -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From skvidal at phy.duke.edu Thu Dec 15 04:39:48 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Wed, 14 Dec 2005 23:39:48 -0500 Subject: mirror synchronization flags? In-Reply-To: References: <1134569858.16389.21.camel@cutter> Message-ID: <1134621588.22019.45.camel@cutter> On Wed, 2005-12-14 at 21:29 +0100, Thomas M Steenholdt wrote: > seth vidal wrote: > > 1. wrong list for this discussion - the mirrors discussion list is more > > appropriate > > 2. you'd need the mirrors to use a consistent script in order to ensure > > that the files were retrieved in a correct order such that the semaphore > > file was retrieved last. This has proved to be harder to get folks to do > > than you would expect. > > 1. okay - i've been looking for the mirrors discussion list and can't > seem to find it - any chance somebody could post a link os something? > It's a private list for mirror admins only. From the way you were speaking I thought you were already a mirror admin. > 2. I can't imagine this would be a problem for the official mirrors? Then you need a better imagination. > I > believe it's a matter of finding a solution (simple protocol if you > will) that allows the mirrors to provide an even better service without > too much fuss. It could also be a great way for a central > (fedoraproject.org or something) status page that could easily poll the > official mirrors for status and such. that's what bouncer is for. -sv From mclasen at redhat.com Thu Dec 15 04:48:36 2005 From: mclasen at redhat.com (Matthias Clasen) Date: Wed, 14 Dec 2005 23:48:36 -0500 Subject: Nit-picking - GNOME "Desktop" menu? In-Reply-To: <20051215043702.GA3211@wolves.durham.nc.us> References: <20051215043702.GA3211@wolves.durham.nc.us> Message-ID: <1134622117.2538.4.camel@localhost.localdomain> On Wed, 2005-12-14 at 23:37 -0500, G.Wolfe Woodbury wrote: > I thought I saw the "Desktop" menu change to "System" > > but now it's back at "Desktop"? > > Just curious. > Thanks for noticing. We probably lost a patch somewhere... From zaitcev at redhat.com Thu Dec 15 05:10:08 2005 From: zaitcev at redhat.com (Pete Zaitcev) Date: Wed, 14 Dec 2005 21:10:08 -0800 Subject: libusual interface [was Re: libusual and ub] In-Reply-To: <20051215031822.GA12020@devserv.devel.redhat.com> References: <20051029193544.096d400e.zaitcev@redhat.com> <20051215031822.GA12020@devserv.devel.redhat.com> Message-ID: <20051214211008.22c1ae47.zaitcev@redhat.com> On Wed, 14 Dec 2005 22:18:22 -0500, Bill Nottingham wrote: > 1) It breaks all 'normal' probing for devices, as the device tables > are removed from the module. You have to hardcode one module or > the other if you're running in an environment where the modules > aren't in 'normal' locations I'd like to see some concrete details or perhaps an example of a breakage. > 3) If you want to change which one you use, since libusual is built-in, > you have to reboot. This seems to be sort of a non-starter. Adding a sysfs method is on my list. It's not hard. I simply forgot that Fedora ships with USB built-in. > a) we blacklist one of the drivers > b) we don't build one of the drivers > c) we turn off automatic binding, and use the bind/unbind features > to handle it Only (c) is somewhat viable, if we are to have ub at all. I saw the discussion on linux-pcmcia which gravitated towards bind/unbind, but the circumstances of it, shall we say, are fisy. Bind/unbind does have some strong points, which revolve around not needing a good will of a driver maintainer when you want to give his driver a boot in the ass. However, while very useful for people who like to hack in a private CVS, this capability gives us exactly nothing in case of ub and usb-storage. As one poster insightfuly observed in that thread, if Roskin's driver and normal driver were merged, there would've been no problem. This brings us to the real meat of the discussion: > 2) It circumvents the normal hotplug mechanisms... while you're still > getting events to userspace about the USB device add, the kernel > is (effectively) handling the event behind your back. Libusual does not circumvent shit. I guess some education is needed here, so please bear with me. Unlike the pcimcia wireless and its tug-of-war, there's only one USB storage driver here, as far as hotplug is concerned. It happens to be called libusual, but I could have called it "grand-unified-usb-storage" or "pot_sex_tux_happy". Do not get hung up on the "lib*" prefix. When libusual is enabled, ub and usb-storage do not exist. Everything regarding the hotplug _including_ alias matching, module locations, etc. etc. works as before. Everything. No circumvention at all. Now, as it happens, libusual loads some other kernel modules to do the work. It's easier to code that way. I could have simply used the #include directive to accomplish the same effect and nobody would be the wiser... right? Well, except the code bloat, because with the current libusual you often have just one back-end loaded. But in fact, #include is how it was originally. The ub started its life as a mode for usb-storage ("threadless" storage). And Matt Dharm would approve that just fine, trust me. But it became apparent very quickly that there was very little code sharing between the two, so I thought it appropriate to split them. Maybe that was a mistake politically. If you want to poke at implementation details beyond libusual, observe that ub is not a replacement for usb-storage. I have them loaded simultaneously and they do drive different devices simultaneously. Plug TEAC CD-210PU into a Rawhide system biased to ub and you'll see. The libusual is far from being the only driver which has components. Just look at md, for instance. I hope that clears things somewhat. But if you have any concrete examples of a breakage, by all means bring them up (e.g. what happens in initrd). -- Pete From notting at redhat.com Thu Dec 15 05:37:41 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 15 Dec 2005 00:37:41 -0500 Subject: libusual interface [was Re: libusual and ub] In-Reply-To: <20051214211008.22c1ae47.zaitcev@redhat.com> References: <20051029193544.096d400e.zaitcev@redhat.com> <20051215031822.GA12020@devserv.devel.redhat.com> <20051214211008.22c1ae47.zaitcev@redhat.com> Message-ID: <20051215053741.GA13787@devserv.devel.redhat.com> Pete Zaitcev (zaitcev at redhat.com) said: > On Wed, 14 Dec 2005 22:18:22 -0500, Bill Nottingham wrote: > > > 1) It breaks all 'normal' probing for devices, as the device tables > > are removed from the module. You have to hardcode one module or > > the other if you're running in an environment where the modules > > aren't in 'normal' locations > > I'd like to see some concrete details or perhaps an example of a breakage. If you aren't using libusual to load the modules (installer), you have to hardcode which module to load somewhere... Jeremy was sending me a (bad :) ) patch for this just the other day... with the ids in the module, you just use the modalias. > > 3) If you want to change which one you use, since libusual is built-in, > > you have to reboot. This seems to be sort of a non-starter. > > Adding a sysfs method is on my list. It's not hard. I simply forgot > that Fedora ships with USB built-in. > > > a) we blacklist one of the drivers > > b) we don't build one of the drivers > > c) we turn off automatic binding, and use the bind/unbind features > > to handle it > > Only (c) is somewhat viable, if we are to have ub at all. Why? If it's better for usage cases XYZ, why not just switch those cases over completely? If it's *not* better, than why switch? > As one poster insightfuly observed in that thread, if Roskin's driver > and normal driver were merged, there would've been no problem. Well, yes. The general issue of 'shipping multiple drivers for one device' is best summed up as "don't do that." > This brings us to the real meat of the discussion: > > > 2) It circumvents the normal hotplug mechanisms... while you're still > > getting events to userspace about the USB device add, the kernel > > is (effectively) handling the event behind your back. > > Libusual does not circumvent shit. I guess some education is needed here, > so please bear with me. > > Unlike the pcimcia wireless and its tug-of-war, there's only one USB > storage driver here, as far as hotplug is concerned. It happens to be > called libusual, but I could have called it "grand-unified-usb-storage" > or "pot_sex_tux_happy". Do not get hung up on the "lib*" prefix. > When libusual is enabled, ub and usb-storage do not exist. Everything > regarding the hotplug _including_ alias matching, module locations, > etc. etc. works as before. Everything. No circumvention at all. You still get a USB hotplug event for the USB device, with the modalias, etc. Obviously, running modprobe with that won't load anything, and libusual has already claimed the device. > If you want to poke at implementation details beyond libusual, observe > that ub is not a replacement for usb-storage. I have them loaded > simultaneously and they do drive different devices simultaneously. > Plug TEAC CD-210PU into a Rawhide system biased to ub and you'll see. Heh, all I have is a craptastic usb-floppy. Bill From seg at haxxed.com Thu Dec 15 07:47:49 2005 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 15 Dec 2005 01:47:49 -0600 Subject: funny user moment (and perhaps a bug) In-Reply-To: <12349.202.12.233.21.1134599074.squirrel@server.twofifty.bpa.nu> References: <1134582427.30388.4.camel@willow.odshp.com> <12349.202.12.233.21.1134599074.squirrel@server.twofifty.bpa.nu> Message-ID: <1134632869.7509.10.camel@hamburger.booze> On Thu, 2005-12-15 at 09:24 +1100, Darren Steven wrote: > Hi, > > Just one question about this thread. Are local and remote the same user? > If so, won't there be some reuse of the daemons etc that handle dbus > interaction etc. > > I know with kde that it is a bit scary running 2x sessions as the same > user. Things don't always behave. Not sure about gnome GNOME brings up a dialog warning you that you're already logged in if you try and log in twice. Its not very strongly worded, but the implication is "please don't do that". One of the more annoying things is you can't run more than one copy of Galeon. Trying to launch a second copy only results in the original copy opening a new window in the original session. And the gnome panel tends to get a bit flaky. Etc... IMHO this is really broken. You should be able to log in to GNOME more than once. After all, you can log in as many times as you want to a shell. Seems like a horrible regression of functionality as far as unix philosophy is concerned. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dwmw2 at infradead.org Thu Dec 15 07:51:22 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 15 Dec 2005 07:51:22 +0000 Subject: funny user moment (and perhaps a bug) In-Reply-To: <1134632869.7509.10.camel@hamburger.booze> References: <1134582427.30388.4.camel@willow.odshp.com> <12349.202.12.233.21.1134599074.squirrel@server.twofifty.bpa.nu> <1134632869.7509.10.camel@hamburger.booze> Message-ID: <1134633082.3791.33.camel@localhost.localdomain> On Thu, 2005-12-15 at 01:47 -0600, Callum Lerwick wrote: > IMHO this is really broken. You should be able to log in to GNOME more > than once. After all, you can log in as many times as you want to a > shell. Seems like a horrible regression of functionality as far as > unix philosophy is concerned. It's probably done on purpose as a usability thing. They probably assume that if you have windows open on more than one machine, you're too stupid to remember which is which; so you have to be banned from doing it in the first place. Some day soon, I expect the GNOME web browser du jour will actively filter out big words from the pages it's displaying, in case they confuse the user. We're not far from that day already, in fact -- Evolution already refuses to display error messages it receives from the SMTP server, _even_ in an optional 'show details' section of the error dialog. Instead it makes up its own 'reasons' for the failure which are often completely incorrect. (Bug #165271) -- dwmw2 From zaitcev at redhat.com Thu Dec 15 08:21:29 2005 From: zaitcev at redhat.com (Pete Zaitcev) Date: Thu, 15 Dec 2005 00:21:29 -0800 Subject: libusual interface [was Re: libusual and ub] In-Reply-To: <20051215053741.GA13787@devserv.devel.redhat.com> References: <20051029193544.096d400e.zaitcev@redhat.com> <20051215031822.GA12020@devserv.devel.redhat.com> <20051214211008.22c1ae47.zaitcev@redhat.com> <20051215053741.GA13787@devserv.devel.redhat.com> Message-ID: <20051215002129.4e9863e0.zaitcev@redhat.com> On Thu, 15 Dec 2005 00:37:41 -0500, Bill Nottingham wrote: > If you aren't using libusual to load the modules (installer), you have to > hardcode which module to load somewhere... Jeremy was sending me a (bad :) ) > patch for this just the other day... with the ids in the module, you just > use the modalias. Suddenly, the problem came into focus. I wish one of you cc:-ed me on it. Like I mentioned previously, when libusual is in effect, modprobing backend drivers makes no sense. With that in mind, I do not see a fundamental problem. We did have an explicit call to modprobe usb-storage. So now we would have something like 'modprobe libusual bias="ub"'. Is there a problem with passing of arguments? > You still get a USB hotplug event for the USB device, with the modalias, > etc. Obviously, running modprobe with that won't load anything, and > libusual has already claimed the device. Have you actually tried it? Loads like a charm here, with 2.6.14-1.1740_FC5 RPM, as it should. This is the scenario: - Since we build with libusual static, there is no hotplug event. module.alias is not involved. - libusual gets ->probe - libusual loads the driver (if not loaded) - The driver attaches to the device > > Plug TEAC CD-210PU into a Rawhide system biased to ub and you'll see. > > Heh, all I have is a craptastic usb-floppy. I must have mixed you with someone. When the story with toggles just broke, people were running with these things, fangs out, fur on fire, as if every engineer had them. Tim bought me one such 210PU at CDW. -- Pete From buildsys at redhat.com Thu Dec 15 08:31:44 2005 From: buildsys at redhat.com (Build System) Date: Thu, 15 Dec 2005 03:31:44 -0500 Subject: rawhide report: 20051215 changes Message-ID: <200512150831.jBF8ViBr023647@porkchop.devel.redhat.com> New package libnotify libnotify notification library New package notify-daemon Notification Daemon Removed package gimp-gap Updated Packages: anaconda-10.90.19-1 ------------------- * Wed Dec 14 2005 Chris Lumens 10.90.19-1 - Use system-config-date for timezone selection UI (#155271). - Work on vnc+shell spawning (dcantrell). - Whiteout fixes (pnasrat, katzj). - Progress bar fixes (katzj). - Depsolving speedups (katzj). avalon-logkit-0:1.2-3jpp_1fc.6 ------------------------------ * Wed Dec 14 2005 Jesse Keating - bump for new gcj - change to not use target= in build.xml binutils-2.16.91.0.3-2 ---------------------- * Wed Dec 14 2005 Jakub Jelinek 2.16.91.0.3-2 - put .gnu.linkonce.d.rel.ro.* sections into relro region classpathx-mail-0:1.0-4jpp_3fc.2 -------------------------------- control-center-1:2.13.3-1 ------------------------- * Wed Dec 14 2005 Matthias Clasen - 1:2.13.3-1 - Update to 2.13.3 - Update patches dcraw-0.0.20051211-1 -------------------- * Wed Dec 14 2005 Nils Philippsen - version of 2005-12-11 - manpage of 2005-09-29 emacs-21.4-11 ------------- * Wed Dec 14 2005 Jens Petersen - 21.4-11 - avoid building with -fstack-protector on i386 to prevent crashing (Jonathan Kamens, #174730) - require xorg-x11-fonts-ISO8859-1-75dpi instead of xorg-x11-fonts-75dpi for modular X (#174614) eog-2.13.3-1 ------------ * Wed Dec 14 2005 Matthias Clasen 2.13.3-1 - Update to 2.13.3 file-roller-2.13.2-1 -------------------- * Wed Dec 14 2005 Matthias Clasen 2.13.2-1 - Update to 2.13.2 - Remove upstreamed patches gedit-1:2.13.0-1 ---------------- * Wed Dec 14 2005 Matthias Clasen - 2.13.0-1 - Update to 2.13.0 - Comment out the fileselector patches for now, these will need updating for the new-mdi branch geronimo-specs-0:1.0-0.M2.2jpp_4fc.2 ------------------------------------ gnome-applets-1:2.13.1-1 ------------------------ * Thu Dec 15 2005 Matthias Clasen 2.13.1-1 - Update to 2.13.1 - Update file lists gnome-desktop-2.13.3-1 ---------------------- * Wed Dec 14 2005 Matthias Clasen - 2.13.3-1 - Update to 2.13.3 gnome-games-1:2.13.3-1 ---------------------- * Thu Dec 15 2005 Matthias Clasen 1:2.13.3-1 - Update to 2.13.3 gnome-libs-1:1.4.1.2.90-47 -------------------------- * Wed Dec 14 2005 Bill Nottingham - 1:1.4.1.2.90-47 - rebuild with -O1 to work around (#175669) gnome-system-monitor-2.13.3-1.1 ------------------------------- * Thu Dec 15 2005 Matthias Clasen 2.13.3-1 - Update to 2.13.3 gnu-crypto-0:2.0.1-1jpp_10fc ---------------------------- * Wed Dec 14 2005 Gary Benson - 0:2.0.1-1jpp_10fc - Rebuild for new gcj. * Tue Dec 13 2005 Jesse Keating - Attempt rebuild for new gcj. * Sun Dec 11 2005 Warren Togami - Attempt rebuild. gphoto2-2.1.6-7.1 ----------------- * Fri Dec 09 2005 Jesse Keating 2.1.6-7.1 - rebuilt grub-0.97-1 ----------- * Wed Dec 14 2005 Peter Jones - 0.97-1 - update to grub 0.97 gtk2-engines-2.7.1-1 -------------------- * Wed Dec 14 2005 Matthias Clasen 2.7.1-1 - Update to 2.7.1 kernel-2.6.14-1.1765_FC5 ------------------------ * Wed Dec 14 2005 Dave Jones - 2.6.15-rc5-git4 - Try 'optimise for size' again. - Silence noisy CD drives that spew msgs when probed whilst empty. * Tue Dec 13 2005 Dave Jones - 2.6.15-rc5-git3 - Use MMIO instead of PIO for 8139too * Tue Dec 13 2005 David Woodhouse - Remove workaround for fixed GCC PR25248 kudzu-1.2.16-1 -------------- * Wed Dec 14 2005 Bill Nottingham - 1.2.16-1 - revert LRMI changes (#175677) libFS-0.99.3-1 -------------- * Tue Dec 13 2005 Mike A. Harris 0.99.3-1 - Updated libFS to version 0.99.3 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. libSM-0.99.3-1 -------------- * Tue Dec 13 2005 Mike A. Harris 0.99.3-1 - Updated libSM to version 0.99.3 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Fri Dec 09 2005 Jesse Keating - rebuilt libXTrap-0.99.2-1 ----------------- * Tue Dec 13 2005 Mike A. Harris 0.99.2-1 - Updated libXTrap to version 0.99.2 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Fri Dec 09 2005 Jesse Keating - rebuilt libXcursor-1.1.5.1-1 -------------------- * Tue Dec 13 2005 Mike A. Harris 1.1.5.1-1 - Updated libXcursor to version 1.1.5.1 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. - Added default index.theme file to set BlueCurve as the default cursor theme to fix bug (#175532). * Fri Dec 09 2005 Jesse Keating - rebuilt libXft-2.1.8.1-1 ---------------- * Tue Dec 13 2005 Mike A. Harris 2.1.8.1-1 - Updated libXft to version 2.1.8.1 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. - Added "Requires: libXrender-devel" to -devel subpackage for (#175465) * Fri Dec 09 2005 Jesse Keating - rebuilt libgnome-2.13.4-1 ----------------- * Wed Dec 14 2005 Matthias Clasen - 2.13.4-1 - Update to 2.13.4 * Fri Dec 09 2005 Jesse Keating - rebuilt * Wed Nov 30 2005 Matthias Clasen - 2.13.2-1 - Update to 2.13.2 - Drop upstreamed patches libgnomeui-2.13.0-1 ------------------- * Wed Dec 14 2005 Matthias Clasen - Update to 2.13.0 * Fri Dec 09 2005 Jesse Keating - rebuilt libselinux-1.29.2-1 ------------------- * Wed Dec 14 2005 Dan Walsh 1.29.2-1 - Upgrade to latest from NSA * Merged call to finish_context_translations from Dan Walsh. This eliminates a memory leak from failing to release memory allocated by libsetrans. libsemanage-1.5.3-2 ------------------- * Wed Dec 14 2005 Dan Walsh 1.5.3-2 - Remove patch since upstream does the right thing * Wed Dec 14 2005 Dan Walsh 1.5.3-1 - Upgrade to latest from NSA * Merged further header cleanups from Ivan Gyurdiev. * Merged toggle modified flag in policydb_modify, fix memory leak in clear_obsolete, polymorphism vs headers fix, and include guards for internal headers patches from Ivan Gyurdiev. libwnck-2.13.3-1 ---------------- * Wed Dec 14 2005 Matthias Clasen - 2.13.3-1 - Update to 2.13.3 * Fri Dec 09 2005 Jesse Keating - rebuilt metacity-2.13.5-1 ----------------- * Thu Dec 15 2005 Matthias Clasen 2.13.5-1 - Update to 2.13.5 * Fri Dec 09 2005 Jesse Keating - rebuilt mysql-5.0.16-2 -------------- * Wed Dec 14 2005 Tom Lane 5.0.16-2 - oops, looks like we want uname -i not uname -m mysqlclient10-3.23.58-8 ----------------------- * Wed Dec 14 2005 Tom Lane 3.23.58-8 - oops, looks like we want uname -i not uname -m * Wed Dec 14 2005 Tom Lane 3.23.58-7 - Make my_config.h architecture-independent for multilib installs; put the original my_config.h into my_config_$ARCH.h - Add license info (COPYING, COPYING.LIB) to the shipped documentation - Add -fwrapv to CFLAGS so that gcc 4.1 doesn't break it - Add mysql-buffer-warning.patch to silence build system security warning mysqlclient14-4.1.14-3 ---------------------- * Wed Dec 14 2005 Tom Lane 4.1.14-3 - oops, looks like we want uname -i not uname -m objectweb-anttask-0:1.2-1jpp_1fc.2.1 ------------------------------------ openh323-1.15.6-4 ----------------- * Wed Dec 14 2005 Alexander Larsson - 1.15.6-4 - Fix gcc 4.1 issue * Fri Dec 09 2005 Jesse Keating - rebuilt opensp-1.5.1-2 -------------- * Wed Dec 14 2005 Tim Waugh 1.5.1-2 - Backported patch from 1.5.2pre1 to fix ArcEngine crash. p6spy-0:1.3-2jpp_3fc.2 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt pango-1.11.1-1 -------------- * Wed Dec 14 2005 Matthias Clasen - 1.11.1-1 - Update to 1.11.1 * Fri Dec 09 2005 Jesse Keating - rebuilt perl-3:5.8.7-8.1 ---------------- * Wed Dec 14 2005 Jason Vas Dias - 3:5.6.7-8.1 - Updated upstream patches for CVE-2005-3962: 26322 , 26331, 26333 php-pear-1:1.4.5-5 ------------------ * Wed Dec 14 2005 Joe Orton 1:1.4.5-5 - set default sig_keydir to /etc/pearkeys - remove ext_dir setting from /etc/pear.conf (#175673) policycoreutils-1.29.2-1 ------------------------ * Wed Dec 14 2005 Dan Walsh 1.29.2-1 - Fix genhomedircon to work in installer - Update to match NSA * Merged patch for chcat script from Dan Walsh. postgresql-8.1.1-2 ------------------ * Wed Dec 14 2005 Tom Lane 8.1.1-2 - oops, looks like we want uname -i not uname -m * Wed Dec 14 2005 Tom Lane 8.1.1-1 - Update to PostgreSQL 8.1.1 - Make pg_config.h architecture-independent for multilib installs; put the original pg_config.h into pg_config_$ARCH.h postgresql-odbc-08.01.0102-1 ---------------------------- * Wed Dec 14 2005 Tom Lane 08.01.0102-1 - Update to version 08.01.0102. - Add buildrequires postgresql-devel (bz #174505) prelink-0.3.6-2 --------------- * Mon Dec 12 2005 Jakub Jelinek 0.3.6-2 - rebuilt with GCC 4.1 - link against newer glibc to fix MALLOC_PERTURB_ bug on 64-bit arches pwlib-1.8.7-3 ------------- * Wed Dec 14 2005 Alexander Larsson - 1.8.7-3 - Fixes for gcc 4.1 * Fri Dec 09 2005 Jesse Keating - rebuilt selinux-doc-1.25.1-1 -------------------- * Wed Dec 14 2005 Dan Walsh 1.25.1-1 - Update to NSA Release version * Updated inode hook section of module report for - change to inode classification logic - introduction of inode_init_security - removal of inode post hooks - generic VFS fallback for security xattrs - canonicalization of getxattr results * Updated socket hook section of module report for - change to socket classification logic - name_connect check * Updated file hook section of module report for - execheap and execstack checks * Fri Dec 09 2005 Jesse Keating - rebuilt selinux-policy-2.1.6-3 ---------------------- * Wed Dec 14 2005 Dan Walsh 2.1.5-3 - Add java unconfined/execmem policy * Wed Dec 14 2005 Dan Walsh 2.1.5-2 - Add file context for /var/cvs - Dontaudit webalizer search of homedir system-config-date-1.7.99.10-1 ------------------------------ * Wed Dec 14 2005 Nils Philippsen 1.7.99.10 - make TimezoneMap more easily subclassable (Chris Lumens), use uniform paren-spacing xalan-j2-0:2.6.0-3jpp_5fc.3 --------------------------- * Tue Dec 13 2005 Jesse Keating 0:2.6.0-3jpp_5fc.3 - patch to not use target= in build.xml * Tue Dec 13 2005 Jesse Keating 0:2.6.0-3jpp_5fc.1 - rebuild again with gcc-4.1 * Fri Dec 09 2005 Warren Togami 0:2.6.0-3jpp_5fc - rebuild with gcc-4.1 xjavadoc-0:1.1-1jpp_2fc.1 ------------------------- * Tue Dec 13 2005 Jesse Keating - bump for new gcj * Thu Sep 08 2005 Florian La Roche - no need to Provide: the name of this package again xterm-207-8 ----------- * Wed Dec 14 2005 Jason Vas Dias - 207-8 - Fix bug 175684: compile with --enable-256-color - Fix bug 155538 addenda - restore '*VT100*backarrowKey:0' yelp-2.13.2-1 ------------- * Thu Dec 15 2005 Matthias Clasen 2.13.2-1 - Update to 2.13.2 * Fri Dec 09 2005 Jesse Keating - rebuilt yum-2.5.0-3 ----------- * Wed Dec 14 2005 Jeremy Katz - 2.5.0-3 - better mirrorlist fix * Wed Dec 14 2005 Jeremy Katz - 2.5.0-2 - revert installyonlyn change that wasn't supposed to get committed - better fix for #175647 that doesn't cause tracebacks when deps need updating too - fix mirrorlist corruption (#175436) Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 carol - 1.8.9.3-1jpp_6fc.i386 requires libgcj.so.6 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel = 0:2.6.14-1.1696_FC5 cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5smp cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 eclipse-bugzilla - 1:0.1.1_fc-5.i386 requires libgcj.so.6 eclipse-cdt - 1:3.0.1-1jpp_1fc.i386 requires libgcj.so.6 eclipse-changelog - 1:2.0.1_fc-22.i386 requires libgcj.so.6 eclipse-ecj - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-jdt - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-pde - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-platform - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-pydev - 1:0.9.3_fc-12.i386 requires libgcj.so.6 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel = 0:2.6.14-1.1696_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jotm - 2.0.5-1jpp_3fc.i386 requires libgcj.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.i386 requires libgcjawt.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 lucene - 1.4.3-1jpp_7fc.i386 requires libgcj.so.6 lucene-demo - 1.4.3-1jpp_7fc.i386 requires libgcj.so.6 monolog - 1.8.6-1jpp_5fc.i386 requires libgcj.so.6 struts - 1.2.4-2jpp_3fc.i386 requires libgcj.so.6 struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.i386 requires libgcj.so.6 systemtap - 0.5-2.i386 requires libdw.so.1(ELFUTILS_0.116) tomcat5 - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 tomcat5-admin-webapps - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 tomcat5-jasper - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 tomcat5-webapps - 5.0.30-8jpp_4fc.i386 requires libgcj.so.6 Broken deps for ia64 ---------------------------------------------------------- carol - 1.8.9.3-1jpp_6fc.ia64 requires libgcj.so.6()(64bit) jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) jotm - 2.0.5-1jpp_3fc.ia64 requires libgcj.so.6()(64bit) lucene - 1.4.3-1jpp_7fc.ia64 requires libgcj.so.6()(64bit) lucene-demo - 1.4.3-1jpp_7fc.ia64 requires libgcj.so.6()(64bit) monolog - 1.8.6-1jpp_5fc.ia64 requires libgcj.so.6()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs struts - 1.2.4-2jpp_3fc.ia64 requires libgcj.so.6()(64bit) struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.ia64 requires libgcj.so.6()(64bit) systemtap - 0.5-2.ia64 requires libdw.so.1(ELFUTILS_0.116)(64bit) tomcat5 - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) tomcat5-admin-webapps - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) tomcat5-jasper - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) tomcat5-webapps - 5.0.30-8jpp_4fc.ia64 requires libgcj.so.6()(64bit) Broken deps for ppc ---------------------------------------------------------- carol - 1.8.9.3-1jpp_6fc.ppc requires libgcj.so.6 cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 eclipse-bugzilla - 1:0.1.1_fc-5.ppc requires libgcj.so.6 eclipse-cdt - 1:3.0.1-1jpp_1fc.ppc requires libgcj.so.6 eclipse-changelog - 1:2.0.1_fc-22.ppc requires libgcj.so.6 eclipse-ecj - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-jdt - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-pde - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-platform - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-pydev - 1:0.9.3_fc-12.ppc requires libgcj.so.6 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jotm - 2.0.5-1jpp_3fc.ppc requires libgcj.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.ppc requires libgcjawt.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 lucene - 1.4.3-1jpp_7fc.ppc requires libgcj.so.6 lucene-demo - 1.4.3-1jpp_7fc.ppc requires libgcj.so.6 monolog - 1.8.6-1jpp_5fc.ppc requires libgcj.so.6 struts - 1.2.4-2jpp_3fc.ppc requires libgcj.so.6 struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.ppc requires libgcj.so.6 systemtap - 0.5-2.ppc requires libdw.so.1(ELFUTILS_0.116) tomcat5 - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 tomcat5-admin-webapps - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 tomcat5-jasper - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 tomcat5-webapps - 5.0.30-8jpp_4fc.ppc requires libgcj.so.6 Broken deps for ppc64 ---------------------------------------------------------- carol - 1.8.9.3-1jpp_6fc.ppc64 requires libgcj.so.6()(64bit) cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) jotm - 2.0.5-1jpp_3fc.ppc64 requires libgcj.so.6()(64bit) lucene - 1.4.3-1jpp_7fc.ppc64 requires libgcj.so.6()(64bit) lucene-demo - 1.4.3-1jpp_7fc.ppc64 requires libgcj.so.6()(64bit) monolog - 1.8.6-1jpp_5fc.ppc64 requires libgcj.so.6()(64bit) struts - 1.2.4-2jpp_3fc.ppc64 requires libgcj.so.6()(64bit) struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.ppc64 requires libgcj.so.6()(64bit) tomcat5 - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) tomcat5-admin-webapps - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) tomcat5-jasper - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) tomcat5-webapps - 5.0.30-8jpp_4fc.ppc64 requires libgcj.so.6()(64bit) Broken deps for s390 ---------------------------------------------------------- carol - 1.8.9.3-1jpp_6fc.s390 requires libgcj.so.6 jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jotm - 2.0.5-1jpp_3fc.s390 requires libgcj.so.6 lucene - 1.4.3-1jpp_7fc.s390 requires libgcj.so.6 lucene-demo - 1.4.3-1jpp_7fc.s390 requires libgcj.so.6 monolog - 1.8.6-1jpp_5fc.s390 requires libgcj.so.6 struts - 1.2.4-2jpp_3fc.s390 requires libgcj.so.6 struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.s390 requires libgcj.so.6 tomcat5 - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 tomcat5-admin-webapps - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 tomcat5-jasper - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 tomcat5-webapps - 5.0.30-8jpp_4fc.s390 requires libgcj.so.6 Broken deps for s390x ---------------------------------------------------------- carol - 1.8.9.3-1jpp_6fc.s390x requires libgcj.so.6()(64bit) jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) jotm - 2.0.5-1jpp_3fc.s390x requires libgcj.so.6()(64bit) libgconf-java - 2.12.0-2.s390x requires libgcj.so.6()(64bit) libgconf-java - 2.12.0-2.s390x requires libcairojava-1.0.so()(64bit) libglade-java - 2.12.0-5.s390x requires libgcj.so.6()(64bit) libglade-java - 2.12.0-5.s390x requires libcairojava-1.0.so()(64bit) libgnome-java - 2.12.0-2.s390x requires libgcj.so.6()(64bit) libgnome-java - 2.12.0-2.s390x requires libcairojava-1.0.so()(64bit) libgtk-java - 2.8.0-7.s390x requires libgcj.so.6()(64bit) libvte-java - 0.11.11-6.3.s390x requires libcairojava-1.0.so()(64bit) lucene - 1.4.3-1jpp_7fc.s390x requires libgcj.so.6()(64bit) lucene-demo - 1.4.3-1jpp_7fc.s390x requires libgcj.so.6()(64bit) monolog - 1.8.6-1jpp_5fc.s390x requires libgcj.so.6()(64bit) struts - 1.2.4-2jpp_3fc.s390x requires libgcj.so.6()(64bit) struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.s390x requires libgcj.so.6()(64bit) tomcat5 - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) tomcat5-admin-webapps - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) tomcat5-jasper - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) tomcat5-webapps - 5.0.30-8jpp_4fc.s390x requires libgcj.so.6()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 carol - 1.8.9.3-1jpp_6fc.x86_64 requires libgcj.so.6()(64bit) cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 eclipse-bugzilla - 1:0.1.1_fc-5.x86_64 requires libgcj.so.6()(64bit) eclipse-cdt - 1:3.0.1-1jpp_1fc.x86_64 requires libgcj.so.6()(64bit) eclipse-changelog - 1:2.0.1_fc-22.x86_64 requires libgcj.so.6()(64bit) eclipse-ecj - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-jdt - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-pde - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-platform - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-pydev - 1:0.9.3_fc-12.x86_64 requires libgcj.so.6()(64bit) gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jotm - 2.0.5-1jpp_3fc.x86_64 requires libgcj.so.6()(64bit) libswt3-gtk2 - 1:3.1.1-1jpp_9fc.x86_64 requires libgcjawt.so.6()(64bit) libswt3-gtk2 - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) lucene - 1.4.3-1jpp_7fc.x86_64 requires libgcj.so.6()(64bit) lucene-demo - 1.4.3-1jpp_7fc.x86_64 requires libgcj.so.6()(64bit) monolog - 1.8.6-1jpp_5fc.x86_64 requires libgcj.so.6()(64bit) struts - 1.2.4-2jpp_3fc.x86_64 requires libgcj.so.6()(64bit) struts-webapps-tomcat5 - 1.2.4-2jpp_3fc.x86_64 requires libgcj.so.6()(64bit) systemtap - 0.5-2.x86_64 requires libdw.so.1(ELFUTILS_0.116)(64bit) tomcat5 - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) tomcat5-admin-webapps - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) tomcat5-jasper - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) tomcat5-webapps - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) From harald at redhat.com Thu Dec 15 08:37:15 2005 From: harald at redhat.com (Harald Hoyer) Date: Thu, 15 Dec 2005 09:37:15 +0100 Subject: rawhide report: 20051214 changes In-Reply-To: <43A037C0.8000608@web.de> References: <200512140830.jBE8UuHq028440@porkchop.devel.redhat.com> <43A037C0.8000608@web.de> Message-ID: <43A12B3B.7050309@redhat.com> Marcus Hartig wrote: > >> udev-077-1 >> ---------- >> * Tue Dec 13 2005 Harald Hoyer - 077-1 >> - version 077 >> - patch to include udevstart2 in udevd and delay daemonize until queue >> is empty > > > Hangs here with 98% used CPU, no soundcard found... > > /sbin/udevsend: connection refused > /sbin/udevsend: connection refused > > Back to 076-1 and it runs again fine. > > Marcus > Do you have a non-Fedora/old kernel? From jkeating at redhat.com Thu Dec 15 08:39:37 2005 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 15 Dec 2005 00:39:37 -0800 Subject: rawhide report: 20051215 changes In-Reply-To: <200512150831.jBF8ViBr023647@porkchop.devel.redhat.com> References: <200512150831.jBF8ViBr023647@porkchop.devel.redhat.com> Message-ID: <1134635773.3005.67.camel@yoda.loki.me> On Thu, 2005-12-15 at 03:31 -0500, Build System wrote: > Broken deps for i386 We are getting much closer to solving these java issues. Some of the packages actually need development work to build cleanly against the gcj in the new gcc. Please bear with us. As you can see the list is getting smaller... -- Jesse Keating Release Engineer: Fedora -- fedora-test-list mailing list fedora-test-list at redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list From m.f.h at web.de Thu Dec 15 09:53:07 2005 From: m.f.h at web.de (Marcus Hartig) Date: Thu, 15 Dec 2005 10:53:07 +0100 Subject: rawhide report: 20051214 changes In-Reply-To: <43A12B3B.7050309@redhat.com> References: <200512140830.jBE8UuHq028440@porkchop.devel.redhat.com> <43A037C0.8000608@web.de> <43A12B3B.7050309@redhat.com> Message-ID: <43A13D03.306@web.de> Harald Hoyer wrote: > Do you have a non-Fedora/old kernel? Yes, 2.6.14.3. Marcus From nicolas.mailhot at laposte.net Thu Dec 15 09:09:52 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 15 Dec 2005 10:09:52 +0100 (CET) Subject: rawhide report: 20051215 changes In-Reply-To: <1134635773.3005.67.camel@yoda.loki.me> References: <200512150831.jBF8ViBr023647@porkchop.devel.redhat.com> <1134635773.3005.67.camel@yoda.loki.me> Message-ID: <12126.192.54.193.25.1134637792.squirrel@rousalka.dyndns.org> On Jeu 15 d?cembre 2005 09:39, Jesse Keating wrote: > On Thu, 2005-12-15 at 03:31 -0500, Build System wrote: >> Broken deps for i386 > > We are getting much closer to solving these java issues. Some of the > packages actually need development work to build cleanly against the gcj > in the new gcc. Please bear with us. As you can see the list is > getting smaller... BTW the new OO.o build pulls in moz, wich is definitely not ok on an x86_64 box (OO.o = i386 -> moz = i386) -- Nicolas Mailhot From pmatilai at laiskiainen.org Thu Dec 15 11:00:43 2005 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 15 Dec 2005 03:00:43 -0800 (PST) Subject: Default cursor theme for FC5. In-Reply-To: <1134586894.7799.7.camel@orange.milkhost.com> References: <439FD56B.8040608@web.de> <12238.194.94.224.254.1134550529.squirrel@arlette.freesurf.fr> <1134586894.7799.7.camel@orange.milkhost.com> Message-ID: On Wed, 14 Dec 2005, Dick Dishkuvek wrote: > Joachim Frieben wrote: >> I think the classic Bluecurve icon cursor them is much better >> anyway than this spinning blue thingy of FC5-rawhide. > > I agree. The spinning blue thing is a distraction, it also makes the > cursor take up too much area, cursors should be a little smaller, at > least by default. The spinning blue thing might look nice on suitable background but it's a total disaster when you 1) Have a blueish background (for example RHEL 4u2 introduced this new thingy and the cursor completely vanishes into the default blue background) 2) Try to click on something when it's spinning. Why doesn't it have an arrow in it at all times, like it has for example on top of firefox window? > There was a comment earlier about the FC4 cursors "busy" animated hour > glass being too busy. This may be true, but it is certainly less busy > than the blue spinning thing. Well at least you could *see* where the cursor is with the spinning hourglass. It never bothered me, apart from suffering from the problem 2) above as well to some extent. - Panu - From benjy.grogan at gmail.com Thu Dec 15 11:01:14 2005 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Thu, 15 Dec 2005 06:01:14 -0500 Subject: Fedora meeting Mono Half-Way Message-ID: Hello: I know this topic has been mentioned over and over, and everyone is irritated by it. But why not meet the Mono project half-way? Why can't the hal-sharp and the dbus-sharp, and gtk-sharp add-ons be included in the fedora packages? At the moment Fedora seems to want absolutely nothing to do with Mono. Why not try to go a little farther and include mono interfaces to dbus, hal, gnome, etc. This means that if someone does install Mono then all the system libraries are ready to do some C# programming. And if a user doesn't install Mono, then the interfaces will lie there useless. Look at it this way, Fedora should try to do the smallest amount possible to embrace Mono. Make it easier on the repositories that do include Mono, so that if I want to install Beagle or F-Spot, I can leave the system libraries on Fedora alone. There are some killer-apps built using Mono. Fedora should get cheeky and see what they can get away. Benjy -------------- next part -------------- An HTML attachment was scrubbed... URL: From nman64 at n-man.com Thu Dec 15 11:28:15 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Thu, 15 Dec 2005 05:28:15 -0600 Subject: Fedora meeting Mono Half-Way In-Reply-To: References: Message-ID: <43A1534F.4040507@n-man.com> Benjy Grogan wrote: > Hello: > > I know this topic has been mentioned over and over, and everyone is > irritated by it. But why not meet the Mono project half-way? Why > can't the hal-sharp and the dbus-sharp, and gtk-sharp add-ons be > included in the fedora packages? Patents > > At the moment Fedora seems to want absolutely nothing to do with > Mono. Why not try to go a little farther and include mono interfaces > to dbus, hal, gnome, etc. This means that if someone does install > Mono then all the system libraries are ready to do some C# > programming. And if a user doesn't install Mono, then the interfaces > will lie there useless. > > Look at it this way, Fedora should try to do the smallest amount > possible to embrace Mono. Make it easier on the repositories that do > include Mono, so that if I want to install Beagle or F-Spot, I can > leave the system libraries on Fedora alone. > > There are some killer-apps built using Mono. Fedora should get cheeky > and see what they can get away. > > Benjy > There's no legal "half-way". Until Mono's legal status is clear (and that is between them and Microsoft), it will not see any embrace from the Fedora Project. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ -- Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From db-fedora at 3di.it Thu Dec 15 11:38:55 2005 From: db-fedora at 3di.it (Davide Bolcioni) Date: Thu, 15 Dec 2005 12:38:55 +0100 Subject: Fedora meeting Mono Half-Way In-Reply-To: References: Message-ID: <43A155CF.4000500@3di.it> Benjy Grogan wrote: > I know this topic has been mentioned over and over, and everyone is > irritated by it. But why not meet the Mono project half-way? Why can't > the hal-sharp and the dbus-sharp, and gtk-sharp add-ons be included in > the fedora packages? > > At the moment Fedora seems to want absolutely nothing to do with Mono. It seems to me you already know the anser to your own question :-) > Look at it this way, Fedora should try to do the smallest amount > possible to embrace Mono. Make it easier on the repositories that do > include Mono, so that if I want to install Beagle or F-Spot, I can leave > the system libraries on Fedora alone. > There are some killer-apps built using Mono. Fedora should get cheeky > and see what they can get away. Myself, I would welcome equivalents of the above apps NOT using mono instead, but that's just me. How many virtual machines and frameworks are we supposed to install ? Davide Bolcioni -- Paranoia is a survival asset. From benjy.grogan at gmail.com Thu Dec 15 12:27:33 2005 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Thu, 15 Dec 2005 07:27:33 -0500 Subject: Fedora meeting Mono Half-Way In-Reply-To: <43A155CF.4000500@3di.it> References: <43A155CF.4000500@3di.it> Message-ID: On 12/15/05, Davide Bolcioni wrote: > > Benjy Grogan wrote: > > > Look at it this way, Fedora should try to do the smallest amount > > possible to embrace Mono. Make it easier on the repositories that do > > include Mono, so that if I want to install Beagle or F-Spot, I can leave > > the system libraries on Fedora alone. > > > There are some killer-apps built using Mono. Fedora should get cheeky > > and see what they can get away. > > Myself, I would welcome equivalents of the above apps NOT using mono > instead, but that's just me. How many virtual machines and frameworks > are we supposed to install ? I know. I'm saying forget about Mono. Just install the mono bindings for d-bus, hal, etc... there are no patent issues with them. Benjy -------------- next part -------------- An HTML attachment was scrubbed... URL: From benjy.grogan at gmail.com Thu Dec 15 12:21:08 2005 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Thu, 15 Dec 2005 07:21:08 -0500 Subject: Fedora meeting Mono Half-Way In-Reply-To: <43A1534F.4040507@n-man.com> References: <43A1534F.4040507@n-man.com> Message-ID: On 12/15/05, Patrick Barnes wrote: > > Benjy Grogan wrote: > > Hello: > > > > I know this topic has been mentioned over and over, and everyone is > > irritated by it. But why not meet the Mono project half-way? Why > > can't the hal-sharp and the dbus-sharp, and gtk-sharp add-ons be > > included in the fedora packages? > Patents There are patents in Mono. But what patent is there in a mono binding do d-bus? D-bus has no patent issues.. So a mono binding is just like a c++ binding, or a c binding.. or any binding. I'm talking about including the mono bindings in Fedoro system libraries. I can't see how there would be a patent in a mono binding for d-bus? Benjy -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora at camperquake.de Thu Dec 15 12:32:05 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Thu, 15 Dec 2005 13:32:05 +0100 Subject: Fedora meeting Mono Half-Way In-Reply-To: References: <43A155CF.4000500@3di.it> Message-ID: <20051215123205.GA12468@ryoko.camperquake.de> On Thu, Dec 15, 2005 at 07:27:33AM -0500, Benjy Grogan wrote: > I know. I'm saying forget about Mono. Just install the mono bindings for > d-bus, hal, etc... there are no patent issues with them. Can you compile those without having Mono? From dcbw at redhat.com Thu Dec 15 13:02:21 2005 From: dcbw at redhat.com (Dan Williams) Date: Thu, 15 Dec 2005 08:02:21 -0500 Subject: Fedora meeting Mono Half-Way In-Reply-To: References: <43A1534F.4040507@n-man.com> Message-ID: <1134651742.2968.2.camel@localhost.localdomain> On Thu, 2005-12-15 at 07:21 -0500, Benjy Grogan wrote: > On 12/15/05, Patrick Barnes wrote: > Benjy Grogan wrote: > > Hello: > > > > I know this topic has been mentioned over and over, and > everyone is > > irritated by it. But why not meet the Mono project > half-way? Why > > can't the hal-sharp and the dbus-sharp, and gtk-sharp > add-ons be > > included in the fedora packages? > Patents > > > There are patents in Mono. But what patent is there in a mono binding > do d-bus? D-bus has no patent issues.. So a mono binding is just > like a c++ binding, or a c binding.. or any binding. > > I'm talking about including the mono bindings in Fedoro system > libraries. > > I can't see how there would be a patent in a mono binding for d-bus? Because you have to have Mono first, before you can build the bindings for dbus/hal/etc. And to make the bindings useful, you must build them. Dan From dcbw at redhat.com Thu Dec 15 13:07:31 2005 From: dcbw at redhat.com (Dan Williams) Date: Thu, 15 Dec 2005 08:07:31 -0500 Subject: funny user moment (and perhaps a bug) In-Reply-To: <1134632869.7509.10.camel@hamburger.booze> References: <1134582427.30388.4.camel@willow.odshp.com> <12349.202.12.233.21.1134599074.squirrel@server.twofifty.bpa.nu> <1134632869.7509.10.camel@hamburger.booze> Message-ID: <1134652051.2968.6.camel@localhost.localdomain> On Thu, 2005-12-15 at 01:47 -0600, Callum Lerwick wrote: > On Thu, 2005-12-15 at 09:24 +1100, Darren Steven wrote: > > Hi, > > > > Just one question about this thread. Are local and remote the same user? > > If so, won't there be some reuse of the daemons etc that handle dbus > > interaction etc. > > > > I know with kde that it is a bit scary running 2x sessions as the same > > user. Things don't always behave. Not sure about gnome > > GNOME brings up a dialog warning you that you're already logged in if > you try and log in twice. Its not very strongly worded, but the > implication is "please don't do that". > > One of the more annoying things is you can't run more than one copy of > Galeon. Trying to launch a second copy only results in the original copy > opening a new window in the original session. And the gnome panel tends > to get a bit flaky. Etc... > > IMHO this is really broken. You should be able to log in to GNOME more > than once. After all, you can log in as many times as you want to a > shell. Seems like a horrible regression of functionality as far as unix > philosophy is concerned. Hmm, what the heck for? That's what Desktop->Preferences->Remote Desktop is for, really. What's the case for logging in twice? Shell and desktop are so totally different that I'm not convinced that they should operate the same way here (not that my opinion matters, really). Should we expect all applications that provide GUI to put in a ton of work to account for a case that a fairly small number of people might actually use? Dan From rc040203 at freenet.de Thu Dec 15 13:37:05 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Thu, 15 Dec 2005 14:37:05 +0100 Subject: funny user moment (and perhaps a bug) In-Reply-To: <1134652051.2968.6.camel@localhost.localdomain> References: <1134582427.30388.4.camel@willow.odshp.com> <12349.202.12.233.21.1134599074.squirrel@server.twofifty.bpa.nu> <1134632869.7509.10.camel@hamburger.booze> <1134652051.2968.6.camel@localhost.localdomain> Message-ID: <1134653825.30243.146.camel@mccallum.corsepiu.local> On Thu, 2005-12-15 at 08:07 -0500, Dan Williams wrote: > On Thu, 2005-12-15 at 01:47 -0600, Callum Lerwick wrote: > > On Thu, 2005-12-15 at 09:24 +1100, Darren Steven wrote: > > > Hi, > > > > > > Just one question about this thread. Are local and remote the same user? > > > If so, won't there be some reuse of the daemons etc that handle dbus > > > interaction etc. > > > > > > I know with kde that it is a bit scary running 2x sessions as the same > > > user. Things don't always behave. Not sure about gnome > > > > GNOME brings up a dialog warning you that you're already logged in if > > you try and log in twice. Its not very strongly worded, but the > > implication is "please don't do that". > > > > One of the more annoying things is you can't run more than one copy of > > Galeon. Trying to launch a second copy only results in the original copy > > opening a new window in the original session. And the gnome panel tends > > to get a bit flaky. Etc... > > > > IMHO this is really broken. You should be able to log in to GNOME more > > than once. After all, you can log in as many times as you want to a > > shell. Seems like a horrible regression of functionality as far as unix > > philosophy is concerned. > > Hmm, what the heck for? Because Unix and Linux are OSes having been designed to work in a network. > That's what Desktop->Preferences->Remote > Desktop is for, really. What's the case for logging in twice? Because you work in a network ... Standard situations: * You login into your personal "desktop" in your office, and leave for another room, on the same network and want to login there ... * Several monitors on your desktop physically connected to different machines, but with a common and shared (networked) /home underneath. > Shell > and desktop are so totally different that I'm not convinced that they > should operate the same way here (not that my opinion matters, really). The problems underneath are the same. Saving a bash history isn't actually different from saving "Desktop"-setup. > Should we expect all applications that provide GUI to put in a ton of > work to account for a case that a fairly small number of people might > actually use? Yes. That's what GUI-toolkits are for. It's not individual applications which should have to care about, it's the GUI-toolkit which should take care about transparently to the user and to the developer. Ralf From brilong at cisco.com Thu Dec 15 13:54:36 2005 From: brilong at cisco.com (Brian Long) Date: Thu, 15 Dec 2005 08:54:36 -0500 Subject: funny user moment (and perhaps a bug) In-Reply-To: <1134652051.2968.6.camel@localhost.localdomain> References: <1134582427.30388.4.camel@willow.odshp.com> <12349.202.12.233.21.1134599074.squirrel@server.twofifty.bpa.nu> <1134632869.7509.10.camel@hamburger.booze> <1134652051.2968.6.camel@localhost.localdomain> Message-ID: <1134654876.4464.22.camel@brilong-lnx> On Thu, 2005-12-15 at 08:07 -0500, Dan Williams wrote: > On Thu, 2005-12-15 at 01:47 -0600, Callum Lerwick wrote: > > On Thu, 2005-12-15 at 09:24 +1100, Darren Steven wrote: > > > Hi, > > > > > > Just one question about this thread. Are local and remote the same user? > > > If so, won't there be some reuse of the daemons etc that handle dbus > > > interaction etc. > > > > > > I know with kde that it is a bit scary running 2x sessions as the same > > > user. Things don't always behave. Not sure about gnome > > > > GNOME brings up a dialog warning you that you're already logged in if > > you try and log in twice. Its not very strongly worded, but the > > implication is "please don't do that". > > > > One of the more annoying things is you can't run more than one copy of > > Galeon. Trying to launch a second copy only results in the original copy > > opening a new window in the original session. And the gnome panel tends > > to get a bit flaky. Etc... > > > > IMHO this is really broken. You should be able to log in to GNOME more > > than once. After all, you can log in as many times as you want to a > > shell. Seems like a horrible regression of functionality as far as unix > > philosophy is concerned. > > Hmm, what the heck for? We have set the following in /etc/profile.d/gconf.sh (and csh equiv): export GCONF_SHARED_LOCKS=1 export GCONF_GLOBAL_LOCKS=1 This allows our folks logged into GNOME on their desktop to also walk into a lab and log into hosts sharing $HOME. Without the above environment variables, GNOME always complained. /Brian/ -- Brian Long | | | IT Data Center Systems | .|||. .|||. Cisco Linux Developer | ..:|||||||:...:|||||||:.. Phone: (919) 392-7363 | C i s c o S y s t e m s From brilong at cisco.com Thu Dec 15 13:56:49 2005 From: brilong at cisco.com (Brian Long) Date: Thu, 15 Dec 2005 08:56:49 -0500 Subject: Default cursor theme for FC5. In-Reply-To: References: <439FD56B.8040608@web.de> <12238.194.94.224.254.1134550529.squirrel@arlette.freesurf.fr> <1134586894.7799.7.camel@orange.milkhost.com> Message-ID: <1134655009.4464.24.camel@brilong-lnx> On Thu, 2005-12-15 at 03:00 -0800, Panu Matilainen wrote: > > On Wed, 14 Dec 2005, Dick Dishkuvek wrote: > > > Joachim Frieben wrote: > >> I think the classic Bluecurve icon cursor them is much better > >> anyway than this spinning blue thingy of FC5-rawhide. > > > > I agree. The spinning blue thing is a distraction, it also makes the > > cursor take up too much area, cursors should be a little smaller, at > > least by default. > > The spinning blue thing might look nice on suitable background but it's a > total disaster when you > 1) Have a blueish background (for example RHEL 4u2 introduced this > new thingy and the cursor completely vanishes into the default > blue background) > 2) Try to click on something when it's spinning. Why doesn't it have an > arrow in it at all times, like it has for example on top of firefox > window? > > > There was a comment earlier about the FC4 cursors "busy" animated hour > > glass being too busy. This may be true, but it is certainly less busy > > than the blue spinning thing. > > Well at least you could *see* where the cursor is with the spinning > hourglass. It never bothered me, apart from suffering from the problem 2) > above as well to some extent. I agree with Panu. Why Red Hat changed the theme between RHEL 4 U1 and U2 is beyond me. /Brian/ -- Brian Long | | | IT Data Center Systems | .|||. .|||. Cisco Linux Developer | ..:|||||||:...:|||||||:.. Phone: (919) 392-7363 | C i s c o S y s t e m s From katzj at redhat.com Thu Dec 15 14:00:33 2005 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 15 Dec 2005 09:00:33 -0500 Subject: libusual interface [was Re: libusual and ub] In-Reply-To: <20051215002129.4e9863e0.zaitcev@redhat.com> References: <20051029193544.096d400e.zaitcev@redhat.com> <20051215031822.GA12020@devserv.devel.redhat.com> <20051214211008.22c1ae47.zaitcev@redhat.com> <20051215053741.GA13787@devserv.devel.redhat.com> <20051215002129.4e9863e0.zaitcev@redhat.com> Message-ID: <1134655233.2864.31.camel@bree.local.net> On Thu, 2005-12-15 at 00:21 -0800, Pete Zaitcev wrote: > On Thu, 15 Dec 2005 00:37:41 -0500, Bill Nottingham wrote: > > > If you aren't using libusual to load the modules (installer), you have to > > hardcode which module to load somewhere... Jeremy was sending me a (bad :) ) > > patch for this just the other day... with the ids in the module, you just > > use the modalias. Hey, to be fair, my patch was just probing for the devices once ub already got loaded. I ignored the question of "how does ub get loaded" since I can guarantee that it happens in anaconda. > Suddenly, the problem came into focus. I wish one of you cc:-ed me on it. > Like I mentioned previously, when libusual is in effect, modprobing > backend drivers makes no sense. With that in mind, I do not see a > fundamental problem. We did have an explicit call to modprobe usb-storage. > So now we would have something like 'modprobe libusual bias="ub"'. > Is there a problem with passing of arguments? With libusual built-in as davej currently has it, it becomes a little bit harder because we don't want to rely on people passing kernel arguments (... history has shown they don't, look back at the fiascos with ramsdisk_size over the years). So if we're going to build libusual in statically, having the sysfs method to change the bias becomes incredibly important (... as then I can just write to the file from the loader and not worry about it) > > You still get a USB hotplug event for the USB device, with the modalias, > > etc. Obviously, running modprobe with that won't load anything, and > > libusual has already claimed the device. > > Have you actually tried it? Loads like a charm here, with 2.6.14-1.1740_FC5 > RPM, as it should. This is the scenario: > - Since we build with libusual static, there is no hotplug event. > module.alias is not involved. > - libusual gets ->probe > - libusual loads the driver (if not loaded) libusual loading the driver is the tricky part here. It works fine on an installed system. The installer is a little trickier because we don't provide all of the same hotplug module loading stuff. At the same time, if I load ub in the loader, the right thing seems to happen, so it doesn't actually cause me much in the way of concern. Jeremy From dcbw at redhat.com Thu Dec 15 14:21:17 2005 From: dcbw at redhat.com (Dan Williams) Date: Thu, 15 Dec 2005 09:21:17 -0500 Subject: funny user moment (and perhaps a bug) In-Reply-To: <1134654876.4464.22.camel@brilong-lnx> References: <1134582427.30388.4.camel@willow.odshp.com> <12349.202.12.233.21.1134599074.squirrel@server.twofifty.bpa.nu> <1134632869.7509.10.camel@hamburger.booze> <1134652051.2968.6.camel@localhost.localdomain> <1134654876.4464.22.camel@brilong-lnx> Message-ID: <1134656478.4766.1.camel@localhost.localdomain> On Thu, 2005-12-15 at 08:54 -0500, Brian Long wrote: > On Thu, 2005-12-15 at 08:07 -0500, Dan Williams wrote: > > Hmm, what the heck for? > > We have set the following in /etc/profile.d/gconf.sh (and csh equiv): > export GCONF_SHARED_LOCKS=1 > export GCONF_GLOBAL_LOCKS=1 > > This allows our folks logged into GNOME on their desktop to also walk > into a lab and log into hosts sharing $HOME. Without the above > environment variables, GNOME always complained. Right, fair enough. I think there's always been the expectation that you can at least share $HOME between two different logons on different machines. I was reading "log into gnome twice on the same machine" rather than sharing $HOME and logging into two different boxes. Dan From brugolsky at telemetry-investments.com Thu Dec 15 14:31:28 2005 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Thu, 15 Dec 2005 09:31:28 -0500 Subject: funny user moment (and perhaps a bug) In-Reply-To: <1134656478.4766.1.camel@localhost.localdomain> References: <1134582427.30388.4.camel@willow.odshp.com> <12349.202.12.233.21.1134599074.squirrel@server.twofifty.bpa.nu> <1134632869.7509.10.camel@hamburger.booze> <1134652051.2968.6.camel@localhost.localdomain> <1134654876.4464.22.camel@brilong-lnx> <1134656478.4766.1.camel@localhost.localdomain> Message-ID: <20051215143128.GD31269@ti64.telemetry-investments.com> On Thu, Dec 15, 2005 at 09:21:17AM -0500, Dan Williams wrote: > On Thu, 2005-12-15 at 08:54 -0500, Brian Long wrote: > > On Thu, 2005-12-15 at 08:07 -0500, Dan Williams wrote: > > > Hmm, what the heck for? > > > > We have set the following in /etc/profile.d/gconf.sh (and csh equiv): > > export GCONF_SHARED_LOCKS=1 > > export GCONF_GLOBAL_LOCKS=1 > > > > This allows our folks logged into GNOME on their desktop to also walk > > into a lab and log into hosts sharing $HOME. Without the above > > environment variables, GNOME always complained. > > Right, fair enough. I think there's always been the expectation that > you can at least share $HOME between two different logons on different > machines. I was reading "log into gnome twice on the same machine" > rather than sharing $HOME and logging into two different boxes. Given the proliferation of session daemons, perhaps the right answer is for people who need this to use Linux-Vserver or OpenVZ to provide isolation similar to running on separate machines with a network share. -Bill From d.jacobfeuerborn at conversis.de Thu Dec 15 15:01:06 2005 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Thu, 15 Dec 2005 16:01:06 +0100 Subject: gstreamer 0.10 In-Reply-To: <1134557227.3026.71.camel@thomas.amantes> References: <1134100748.11873.9.camel@localhost.localdomain> <43999BEE.6030002@conversis.de> <1134143154.11873.55.camel@localhost.localdomain> <3adc77210512111221u409de288l622211bdc089adf0@mail.gmail.com> <439CBBC0.2070201@conversis.de> <1134557227.3026.71.camel@thomas.amantes> Message-ID: <43A18532.7010506@conversis.de> Thomas Vander Stichele wrote: > On Mon, 2005-12-12 at 00:52 +0100, Dennis Jacobfeuerborn wrote: >> Naheem Zaffar wrote: >>> I did not think there would be a day fedora would shy away from the >>> latest stuff. If there are problesm, well that is the point of rawhide >>> and test releases. >> Right now the problem is that software that actually makes use of gstreamer >> 0.10 seems to be hard to come by. > > Software that has support for 0.10 atm: > > - Flumotion (http://www.flumotion.net/) > - totem (configure option in CVS HEAD) > - jamboree (CVS HEAD) > - pitivi (CVS HEAD) > - Rhythmbox (CVS HEAD) > - Banshee (HEAD) > - bmpx (HEAD) > > Given that 0.10 has been out for nine days at this point, that's a > pretty good start. releases of these are expected this month. If people can get out stable releases this fast then that's a good reason to include gstreamer 0.10 indeed. My worry was that since it has only been out for nine days as you said and there are virtually no released applications yet there is very little real-world data out there about the stability of gst 0.10. >> After giving up on Banshee I tried >> Rhythmbox HEAD which kinda works but not really. Playing a file doesn't >> work right away and I have to give the seekbar a little nudge to make it >> start playing. > > Does this happen always ? Every type of file ? More info would help. Yes, it happens always and with every file. Well, more info about what info you need would help too. :) (see below) >> Unfortunately that's actually more than I get out of >> Rhythmbox with gstreamer 0.8 (see >> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=174917 ). > > Hm, two things: > a) a bug report on rhythmbox is probably better put into rhythmbox's > bugzilla. I was mostly filed this bug for completeness sake and since I didn't get any sort of reply on it anyway I'm now more concerned with gst 0.10. > b) the bug report is short on details. What version of GStreamer ? What > types of files ? What audio sink ? What CPU ? ... I filed it against Fedora-devel so the versions of the various bits are whatever is currently in rawhide. (top to bottom: rhythmbox-0.9.2-3.1, gstreamer-0.8.11-2.1, alsa-lib-1.0.10rf-3, kernel-2.6.14-1.1752_FC5) It happens with all types of files and the audio sink is the, well, default one (my guess is alsa). Rhythmbox does not have any option to specify the sink. The CPU is an AMD Athlon(tm) XP 2000+ although I'm not sure what the CPU would have to do with it. The audio card is an M-Audio Audiophile 2496 using the ice1712 driver. Regards, Dennis From paul at all-the-johnsons.co.uk Thu Dec 15 15:16:11 2005 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Thu, 15 Dec 2005 15:16:11 +0000 Subject: rawhide report: 20051215 changes In-Reply-To: <200512150831.jBF8ViBr023647@porkchop.devel.redhat.com> References: <200512150831.jBF8ViBr023647@porkchop.devel.redhat.com> Message-ID: <1134659771.4124.100.camel@T7.Linux> Hi, > Broken deps for x86_64 > eclipse-bugzilla - 1:0.1.1_fc-5.x86_64 requires libgcj.so.6()(64bit) > eclipse-cdt - 1:3.0.1-1jpp_1fc.x86_64 requires libgcj.so.6()(64bit) > eclipse-changelog - 1:2.0.1_fc-22.x86_64 requires libgcj.so.6()(64bit) > eclipse-ecj - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) > eclipse-jdt - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) > eclipse-pde - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) > eclipse-platform - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) > eclipse-pydev - 1:0.9.3_fc-12.x86_64 requires libgcj.so.6()(64bit) > tomcat5 - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) > tomcat5-admin-webapps - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) > tomcat5-jasper - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) > tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) > tomcat5-webapps - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) Any chance of putting these on tomorrows build? TTFN Paul -- main(t,_,a) char*a;{return!0 References: <43A155CF.4000500@3di.it> Message-ID: On 12/15/05, Davide Bolcioni wrote: > > There are some killer-apps built using Mono. Fedora should get cheeky > > and see what they can get away. > > Myself, I would welcome equivalents of the above apps NOT using mono > instead, but that's just me. How many virtual machines and frameworks > are we supposed to install ? > Actually, I am wondering about this topic from some time, that is, what is done in Beagle with Mono that is so difficult to be done in C or C++ ? From alexl at redhat.com Thu Dec 15 16:03:32 2005 From: alexl at redhat.com (Alexander Larsson) Date: Thu, 15 Dec 2005 17:03:32 +0100 Subject: Fedora meeting Mono Half-Way In-Reply-To: References: <43A155CF.4000500@3di.it> Message-ID: <1134662612.28842.121.camel@greebo> On Thu, 2005-12-15 at 16:42 +0100, Gianluca Sforna wrote: > On 12/15/05, Davide Bolcioni wrote: > > > There are some killer-apps built using Mono. Fedora should get cheeky > > > and see what they can get away. > > > > Myself, I would welcome equivalents of the above apps NOT using mono > > instead, but that's just me. How many virtual machines and frameworks > > are we supposed to install ? > > > > Actually, I am wondering about this topic from some time, that is, > what is done in Beagle with Mono that is so difficult to be done in C > or C++ ? Its not beagle the app that is problematic, it is mono the framework. However beagle doesn't work without mono, so shipping beagle without mono is not an option. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an unconventional devious cat burglar for the 21st century. She's an orphaned red-headed vampire with her own daytime radio talk show. They fight crime! From pbrobinson at gmail.com Thu Dec 15 16:06:10 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Thu, 15 Dec 2005 16:06:10 +0000 Subject: Fedora meeting Mono Half-Way In-Reply-To: <1134662612.28842.121.camel@greebo> References: <43A155CF.4000500@3di.it> <1134662612.28842.121.camel@greebo> Message-ID: <5256d0b0512150806y7c49e6fbtcfadec0b0576c286@mail.gmail.com> On 12/15/05, Alexander Larsson wrote: > On Thu, 2005-12-15 at 16:42 +0100, Gianluca Sforna wrote: > > On 12/15/05, Davide Bolcioni wrote: > > > > There are some killer-apps built using Mono. Fedora should get cheeky > > > > and see what they can get away. > > > > > > Myself, I would welcome equivalents of the above apps NOT using mono > > > instead, but that's just me. How many virtual machines and frameworks > > > are we supposed to install ? > > > > > > > Actually, I am wondering about this topic from some time, that is, > > what is done in Beagle with Mono that is so difficult to be done in C > > or C++ ? > > Its not beagle the app that is problematic, it is mono the framework. > However beagle doesn't work without mono, so shipping beagle without > mono is not an option. What I think he was asking was what functionality does Mono have that makes it easier to develop in Mono rather than C or C++. My answer to that question is that I believe there is nothing but Mono being a Novell/Ximian developed env they are using Beagle (as well as F-Spot and a couple of others) as a proof of concept to prove that its a good platform etc. and also as a sort of if you want this you have to also have this. P From alexl at redhat.com Thu Dec 15 16:09:21 2005 From: alexl at redhat.com (Alexander Larsson) Date: Thu, 15 Dec 2005 17:09:21 +0100 Subject: bittorrent in core? what frontend? Message-ID: <1134662961.28842.128.camel@greebo> At some point in time we in the desktop group discussed shipping bittorrent and a nice frontend in fedora core. Since more and more people start to use this as a standard way of distributing software (e.g. fedora core itself uses this) it really should be supported in a default desktop install, so that when you click on a torrent file in the browser something "nice" happens. What are peoples opinions on this? Another question is what frontend to use as a default. bittorrent itself ships with a wxPython based frontend (bittorrent-gui, availible with bittorrent in fedora extras). Another frontend is gnome-bt (http://gnome-bt.sourceforge.net/) which is designed more like a simple *.torrent mime handler rather than a full bittorrent app. Ubuntu defaults to this i think. I packaged gnome-bt at: http://people.redhat.com/alexl/files/gnome-bt-0.0.22-1.noarch.rpm http://people.redhat.com/alexl/files/gnome-bt-0.0.22-1.src.rpm I don't use bittorrent all that much. What do people think about these two frontends? Are there other interesting ones? =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an uncontrollable guitar-strumming farmboy with a robot buddy named Sparky. She's a radical goth Valkyrie fleeing from a Satanic cult. They fight crime! From paul at city-fan.org Thu Dec 15 16:12:03 2005 From: paul at city-fan.org (Paul Howarth) Date: Thu, 15 Dec 2005 16:12:03 +0000 Subject: bittorrent in core? what frontend? In-Reply-To: <1134662961.28842.128.camel@greebo> References: <1134662961.28842.128.camel@greebo> Message-ID: <43A195D3.2090302@city-fan.org> Alexander Larsson wrote: > At some point in time we in the desktop group discussed shipping > bittorrent and a nice frontend in fedora core. Since more and more > people start to use this as a standard way of distributing software > (e.g. fedora core itself uses this) it really should be supported in a > default desktop install, so that when you click on a torrent file in the > browser something "nice" happens. > > What are peoples opinions on this? > > Another question is what frontend to use as a default. bittorrent itself > ships with a wxPython based frontend (bittorrent-gui, availible with > bittorrent in fedora extras). Another frontend is gnome-bt > (http://gnome-bt.sourceforge.net/) which is designed more like a simple > *.torrent mime handler rather than a full bittorrent app. Ubuntu > defaults to this i think. > > I packaged gnome-bt at: > http://people.redhat.com/alexl/files/gnome-bt-0.0.22-1.noarch.rpm > http://people.redhat.com/alexl/files/gnome-bt-0.0.22-1.src.rpm > > I don't use bittorrent all that much. What do people think about these > two frontends? Are there other interesting ones? Upstream bittorrent stopped using wxPython at 3.90; the current -gui package used in bittorrent 4.x is pygtk2-based and I don't see any advantages that gnome-bt has over it personally. I think the only viable alternative would be azureus really, which is java-based. Paul. From ph18 at cornell.edu Thu Dec 15 16:13:19 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Thu, 15 Dec 2005 11:13:19 -0500 Subject: Fedora meeting Mono Half-Way In-Reply-To: References: <43A155CF.4000500@3di.it> Message-ID: <43A1961F.8060706@cornell.edu> Gianluca Sforna wrote: > Actually, I am wondering about this topic from some time, that is, > what is done in Beagle with Mono that is so difficult to be done in C > or C++ ? > Automatic memory management, no buffer overflows because the authors didn't do string handling with superhuman care, OO programming model where people use objects to model the problem domain rather than spend 20 years arguing about how to implement a linked list. From perbj at sbcglobal.net Thu Dec 15 16:20:25 2005 From: perbj at sbcglobal.net (Per Bjornsson) Date: Thu, 15 Dec 2005 08:20:25 -0800 Subject: funny user moment (and perhaps a bug) In-Reply-To: <1134653825.30243.146.camel@mccallum.corsepiu.local> References: <1134582427.30388.4.camel@willow.odshp.com> <12349.202.12.233.21.1134599074.squirrel@server.twofifty.bpa.nu> <1134632869.7509.10.camel@hamburger.booze> <1134652051.2968.6.camel@localhost.localdomain> <1134653825.30243.146.camel@mccallum.corsepiu.local> Message-ID: <1134663626.17385.139.camel@localhost.localdomain> On Thu, 2005-12-15 at 14:37 +0100, Ralf Corsepius wrote: > Standard situations: > * You login into your personal "desktop" in your office, and leave for > another room, on the same network and want to login there ... > * Several monitors on your desktop physically connected to different > machines, but with a common and shared (networked) /home underneath. Actually that is very different from logging in several times on the same machine. (Unless you use LTSP I guess, but that's not what you said.) logging in multiple times on separate machines sharing a networked /home is supposed to be supported in Gnome; it has been problematic occasionally but that's because of bugs. /Per From michael.favia at insitesinc.com Thu Dec 15 16:21:44 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Thu, 15 Dec 2005 10:21:44 -0600 Subject: bittorrent in core? what frontend? In-Reply-To: <1134662961.28842.128.camel@greebo> References: <1134662961.28842.128.camel@greebo> Message-ID: <43A19818.7090402@insitesinc.com> Alexander Larsson wrote: > At some point in time we in the desktop group discussed shipping > bittorrent and a nice frontend in fedora core. Since more and more > people start to use this as a standard way of distributing software > (e.g. fedora core itself uses this) it really should be supported in a > default desktop install, so that when you click on a torrent file in the > browser something "nice" happens. > > What are peoples opinions on this? > > Another question is what frontend to use as a default. bittorrent itself > ships with a wxPython based frontend (bittorrent-gui, availible with > bittorrent in fedora extras). Another frontend is gnome-bt > (http://gnome-bt.sourceforge.net/) which is designed more like a simple > *.torrent mime handler rather than a full bittorrent app. Ubuntu > defaults to this i think. > > I packaged gnome-bt at: > http://people.redhat.com/alexl/files/gnome-bt-0.0.22-1.noarch.rpm > http://people.redhat.com/alexl/files/gnome-bt-0.0.22-1.src.rpm > > I don't use bittorrent all that much. What do people think about these > two frontends? Are there other interesting ones? Java haters unite but i find the azureus bt client to be useful and full featured. It handles UPnP through the router and allows me to set importance values on individual files in a torrent as well as manage full bandwidth throttling. Using these features i only have to download CD's 1 and 2 of a 4 cd distro torrent if id like and i dont have to swamp the network to do it. I havent tried it for compliance ontop of the fedora "free" java stack but it runs quickly on my old clunker on the sun JVM. Take a look at: http://azureus.sourceforge.net/ -mf From ph18 at cornell.edu Thu Dec 15 16:24:46 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Thu, 15 Dec 2005 11:24:46 -0500 Subject: bittorrent in core? what frontend? In-Reply-To: <1134662961.28842.128.camel@greebo> References: <1134662961.28842.128.camel@greebo> Message-ID: <43A198CE.4000101@cornell.edu> Alexander Larsson wrote: > What are peoples opinions on this? > I've always had a bad time with the Python bittorrent clients (historically isn't hasn't kept up with changes in Python.) Azuereus is great, but I don't know if it works with the Java stack that ships with FC. From linville at redhat.com Thu Dec 15 16:27:12 2005 From: linville at redhat.com (John W. Linville) Date: Thu, 15 Dec 2005 11:27:12 -0500 Subject: kernel-2.6.14-1.1653_FC4.netdev.6? In-Reply-To: <20051215010803.GE9801@redhat.com> References: <43A05044.7060803@cygnusx-1.org> <20051215005152.GF26108@rathann.pekin.waw.pl> <20051215010803.GE9801@redhat.com> Message-ID: <20051215162712.GC16712@redhat.com> On Wed, Dec 14, 2005 at 08:08:03PM -0500, John W. Linville wrote: > On Thu, Dec 15, 2005 at 01:51:52AM +0100, Dominik 'Rathann' Mierzejewski wrote: > > On Wednesday, 14 December 2005 at 18:03, Nathan Grennan wrote: > > > I am interested in moving to kernel-2.6.14-1.1653_FC4, and I am > > > curious when kernel-2.6.14-1.1653_FC4.netdev.6 will be out. > > > > Me too. I'm interested in updated ipw2200 driver in particular. > > Workin' on it... kernel-2.6.14-1.1653_FC4.netdev.6 is available now: http://people.redhat.com/linville/kernels/fedora-netdev/ Thanks! John -- John W. Linville linville at redhat.com From dragoran at feuerpokemon.de Thu Dec 15 16:32:37 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Thu, 15 Dec 2005 17:32:37 +0100 Subject: Fedora meeting Mono Half-Way In-Reply-To: <1134651742.2968.2.camel@localhost.localdomain> References: <43A1534F.4040507@n-man.com> <1134651742.2968.2.camel@localhost.localdomain> Message-ID: <43A19AA5.3000604@feuerpokemon.de> Dan Williams wrote: >On Thu, 2005-12-15 at 07:21 -0500, Benjy Grogan wrote: > > >>On 12/15/05, Patrick Barnes wrote: >> Benjy Grogan wrote: >> > Hello: >> > >> > I know this topic has been mentioned over and over, and >> everyone is >> > irritated by it. But why not meet the Mono project >> half-way? Why >> > can't the hal-sharp and the dbus-sharp, and gtk-sharp >> add-ons be >> > included in the fedora packages? >> Patents >> >> >>There are patents in Mono. But what patent is there in a mono binding >>do d-bus? D-bus has no patent issues.. So a mono binding is just >>like a c++ binding, or a c binding.. or any binding. >> >>I'm talking about including the mono bindings in Fedoro system >>libraries. >> >>I can't see how there would be a patent in a mono binding for d-bus? >> >> > >Because you have to have Mono first, before you can build the bindings >for dbus/hal/etc. And to make the bindings useful, you must build them. > >Dan > > > > but what about a %with_mono flag in the spec file which lets us build it without using third party packages? like its done with the bytecode interpreter in freetype. (or the ntfs kernel module but this is something different) From giallu at gmail.com Thu Dec 15 16:35:11 2005 From: giallu at gmail.com (Gianluca Sforna) Date: Thu, 15 Dec 2005 17:35:11 +0100 Subject: Fedora meeting Mono Half-Way In-Reply-To: <43A1961F.8060706@cornell.edu> References: <43A155CF.4000500@3di.it> <43A1961F.8060706@cornell.edu> Message-ID: On 12/15/05, Paul A Houle wrote: > Gianluca Sforna wrote: > > Actually, I am wondering about this topic from some time, that is, > > what is done in Beagle with Mono that is so difficult to be done in C > > or C++ ? > > > Automatic memory management, no buffer overflows because the > authors didn't do string handling with superhuman care, OO programming > model where people use objects to model the problem domain rather than > spend 20 years arguing about how to implement a linked list. > Despite I know _zero_ C#, your list list seems to be quite fulfilled by C++ (or, if you want to stick to higher level languages, python). I guess Peter's answer should be nearer to reality... From seanlkml at sympatico.ca Thu Dec 15 16:39:23 2005 From: seanlkml at sympatico.ca (Sean) Date: Thu, 15 Dec 2005 11:39:23 -0500 (EST) Subject: bittorrent in core? what frontend? In-Reply-To: <1134662961.28842.128.camel@greebo> References: <1134662961.28842.128.camel@greebo> Message-ID: On Thu, December 15, 2005 11:09 am, Alexander Larsson said: > I don't use bittorrent all that much. What do people think about these > two frontends? Are there other interesting ones? Azureus is really the best. Just did a quick google to see if gcj 4.1 can compile it, and sure enough Slashdot says it works, so it must be true ;) Cheers, Sean From lmacken at redhat.com Thu Dec 15 16:42:16 2005 From: lmacken at redhat.com (Luke Macken) Date: Thu, 15 Dec 2005 11:42:16 -0500 Subject: bittorrent in core? what frontend? In-Reply-To: <43A195D3.2090302@city-fan.org> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> Message-ID: <20051215164216.GB9717@tomservo.boston.redhat.com> On Thu, Dec 15, 2005 at 04:12:03PM +0000, Paul Howarth wrote: | Alexander Larsson wrote: | >At some point in time we in the desktop group discussed shipping | >bittorrent and a nice frontend in fedora core. Since more and more | >people start to use this as a standard way of distributing software | >(e.g. fedora core itself uses this) it really should be supported in a | >default desktop install, so that when you click on a torrent file in the | >browser something "nice" happens. | > | >What are peoples opinions on this? | > | >Another question is what frontend to use as a default. bittorrent itself | >ships with a wxPython based frontend (bittorrent-gui, availible with | >bittorrent in fedora extras). Another frontend is gnome-bt | >(http://gnome-bt.sourceforge.net/) which is designed more like a simple | >*.torrent mime handler rather than a full bittorrent app. Ubuntu | >defaults to this i think. | > | >I packaged gnome-bt at: | >http://people.redhat.com/alexl/files/gnome-bt-0.0.22-1.noarch.rpm | >http://people.redhat.com/alexl/files/gnome-bt-0.0.22-1.src.rpm | > | >I don't use bittorrent all that much. What do people think about these | >two frontends? Are there other interesting ones? | | Upstream bittorrent stopped using wxPython at 3.90; the current -gui | package used in bittorrent 4.x is pygtk2-based and I don't see any | advantages that gnome-bt has over it personally. +1 If any bittorrent client is to slip into core, my vote is for the upstream default. | I think the only viable alternative would be azureus really, which is | java-based. Azureus is OK, but is a bit feature-bloated IMO for a pice of software that just needs to manage downloads (I mean, seriously, do people really need an IRC client built into their bittorrent client?). I think that the functionality of the standard upstream gui should satisfy all of our core needs. luke From michael.favia at insitesinc.com Thu Dec 15 16:45:35 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Thu, 15 Dec 2005 10:45:35 -0600 Subject: bittorrent in core? what frontend? In-Reply-To: <20051215164216.GB9717@tomservo.boston.redhat.com> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> Message-ID: <43A19DAF.6050407@insitesinc.com> Luke Macken wrote: > On Thu, Dec 15, 2005 at 04:12:03PM +0000, Paul Howarth wrote: > | Alexander Larsson wrote: > | >At some point in time we in the desktop group discussed shipping > | >bittorrent and a nice frontend in fedora core. Since more and more > | >people start to use this as a standard way of distributing software > | >(e.g. fedora core itself uses this) it really should be supported in a > | >default desktop install, so that when you click on a torrent file in the > | >browser something "nice" happens. > | > > | >What are peoples opinions on this? > | > > | >Another question is what frontend to use as a default. bittorrent itself > | >ships with a wxPython based frontend (bittorrent-gui, availible with > | >bittorrent in fedora extras). Another frontend is gnome-bt > | >(http://gnome-bt.sourceforge.net/) which is designed more like a simple > | >*.torrent mime handler rather than a full bittorrent app. Ubuntu > | >defaults to this i think. > | > > | >I packaged gnome-bt at: > | >http://people.redhat.com/alexl/files/gnome-bt-0.0.22-1.noarch.rpm > | >http://people.redhat.com/alexl/files/gnome-bt-0.0.22-1.src.rpm > | > > | >I don't use bittorrent all that much. What do people think about these > | >two frontends? Are there other interesting ones? > | > | Upstream bittorrent stopped using wxPython at 3.90; the current -gui > | package used in bittorrent 4.x is pygtk2-based and I don't see any > | advantages that gnome-bt has over it personally. > > +1 > > If any bittorrent client is to slip into core, my vote is for the > upstream default. > > | I think the only viable alternative would be azureus really, which is > | java-based. > > Azureus is OK, but is a bit feature-bloated IMO for a pice of software > that just needs to manage downloads (I mean, seriously, do people really > need an IRC client built into their bittorrent client?). I think that > the functionality of the standard upstream gui should satisfy all of our > core needs. Agreed about the IRC client but does it allow bandwidth throttling, file priority selection (High, low, dont get), and UPnP router management? I haven't used it because azureus has satisfied all my needs just wondering what it provided and that rpm looks so far away. -mf From skvidal at phy.duke.edu Thu Dec 15 16:49:15 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 15 Dec 2005 11:49:15 -0500 Subject: bittorrent in core? what frontend? In-Reply-To: <20051215164216.GB9717@tomservo.boston.redhat.com> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> Message-ID: <1134665355.25232.10.camel@cutter> > Azureus is OK, but is a bit feature-bloated IMO for a pice of software > that just needs to manage downloads (I mean, seriously, do people really > need an IRC client built into their bittorrent client?). But where besides irc do you go to find out where to get the 0-day Warez and pr0n.. err nevermind. just forget I said anything. :) -sv From sundaram at redhat.com Thu Dec 15 16:49:53 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 15 Dec 2005 22:19:53 +0530 Subject: funny user moment (and perhaps a bug) In-Reply-To: <20051215143128.GD31269@ti64.telemetry-investments.com> References: <1134582427.30388.4.camel@willow.odshp.com> <12349.202.12.233.21.1134599074.squirrel@server.twofifty.bpa.nu> <1134632869.7509.10.camel@hamburger.booze> <1134652051.2968.6.camel@localhost.localdomain> <1134654876.4464.22.camel@brilong-lnx> <1134656478.4766.1.camel@localhost.localdomain> <20051215143128.GD31269@ti64.telemetry-investments.com> Message-ID: <43A19EB1.6030608@redhat.com> Hi > >Given the proliferation of session daemons, perhaps the right answer is for >people who need this to use Linux-Vserver or OpenVZ to provide isolation >similar to running on separate machines with a network share. > > Unless these patches get upstream, they are not the right answer - atleast for Fedora. regards Rahul From overholt at redhat.com Thu Dec 15 17:02:56 2005 From: overholt at redhat.com (Andrew Overholt) Date: Thu, 15 Dec 2005 12:02:56 -0500 Subject: rawhide report: 20051215 changes In-Reply-To: <1134659771.4124.100.camel@T7.Linux> References: <200512150831.jBF8ViBr023647@porkchop.devel.redhat.com> <1134659771.4124.100.camel@T7.Linux> Message-ID: <1134666176.29159.3.camel@tophat.toronto.redhat.com> On Thu, 2005-12-15 at 15:16 +0000, Paul F. Johnson wrote: > Hi, > > > Broken deps for x86_64 > > eclipse-bugzilla - 1:0.1.1_fc-5.x86_64 requires libgcj.so.6()(64bit) > > eclipse-cdt - 1:3.0.1-1jpp_1fc.x86_64 requires libgcj.so.6()(64bit) > > eclipse-changelog - 1:2.0.1_fc-22.x86_64 requires libgcj.so.6()(64bit) > > eclipse-ecj - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) > > eclipse-jdt - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) > > eclipse-pde - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) > > eclipse-platform - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) > > eclipse-pydev - 1:0.9.3_fc-12.x86_64 requires libgcj.so.6()(64bit) > > tomcat5 - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) > > tomcat5-admin-webapps - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) > > tomcat5-jasper - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) > > tomcat5-servlet-2.4-api - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) > > tomcat5-webapps - 5.0.30-8jpp_4fc.x86_64 requires libgcj.so.6()(64bit) > > Any chance of putting these on tomorrows build? I've been trying to get Eclipse to build for a few days now. There was a gcc bug which got fixed yesterday by Andrew Haley but today I'm running into https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175833 . I can duplicate locally now so hopefully we can get this fixed and have builds. I can really speak for tomcat, but IIRC, it needs a bytecode compiler which is provided by eclipse-ecj. Sorry this has taken so long. Andrew From alexl at redhat.com Thu Dec 15 17:04:58 2005 From: alexl at redhat.com (Alexander Larsson) Date: Thu, 15 Dec 2005 18:04:58 +0100 Subject: Fedora meeting Mono Half-Way In-Reply-To: References: <43A155CF.4000500@3di.it> <43A1961F.8060706@cornell.edu> Message-ID: <1134666299.28842.132.camel@greebo> On Thu, 2005-12-15 at 17:35 +0100, Gianluca Sforna wrote: > On 12/15/05, Paul A Houle wrote: > > Gianluca Sforna wrote: > > > Actually, I am wondering about this topic from some time, that is, > > > what is done in Beagle with Mono that is so difficult to be done in C > > > or C++ ? > > > > > Automatic memory management, no buffer overflows because the > > authors didn't do string handling with superhuman care, OO programming > > model where people use objects to model the problem domain rather than > > spend 20 years arguing about how to implement a linked list. > > > > Despite I know _zero_ C#, your list list seems to be quite fulfilled > by C++ (or, if you want to stick to higher level languages, python). I > guess Peter's answer should be nearer to reality... I'm not sure what you mean. You can have whatever opinions of various languages you like. The fact is that beagle is written in c#, thus requiring mono. Can you rewrite something similar to beagle in another language? Of course you can, but thats a completely different proposition than adding "beagle without mono". For one, it would require multiple man years of work (beagle has seen a lot of work by many people already). =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a jaded umbrella-wielding firefighter living undercover at Ringling Bros. Circus. She's a cold-hearted red-headed nun with a knack for trouble. They fight crime! From benjy.grogan at gmail.com Thu Dec 15 17:03:59 2005 From: benjy.grogan at gmail.com (Benjy Grogan) Date: Thu, 15 Dec 2005 12:03:59 -0500 Subject: Fedora meeting Mono Half-Way In-Reply-To: <43A19AA5.3000604@feuerpokemon.de> References: <43A1534F.4040507@n-man.com> <1134651742.2968.2.camel@localhost.localdomain> <43A19AA5.3000604@feuerpokemon.de> Message-ID: On 12/15/05, dragoran wrote: > > Dan Williams wrote: > > >On Thu, 2005-12-15 at 07:21 -0500, Benjy Grogan wrote: > > > > > >>On 12/15/05, Patrick Barnes wrote: > >> Benjy Grogan wrote: > >> > Hello: > >> > > >> > I know this topic has been mentioned over and over, and > >> everyone is > >> > irritated by it. But why not meet the Mono project > >> half-way? Why > >> > can't the hal-sharp and the dbus-sharp, and gtk-sharp > >> add-ons be > >> > included in the fedora packages? > >> Patents > >> > >> > >>There are patents in Mono. But what patent is there in a mono binding > >>do d-bus? D-bus has no patent issues.. So a mono binding is just > >>like a c++ binding, or a c binding.. or any binding. > >> > >>I'm talking about including the mono bindings in Fedoro system > >>libraries. > >> > >>I can't see how there would be a patent in a mono binding for d-bus? > >> > >> > > > >Because you have to have Mono first, before you can build the bindings > >for dbus/hal/etc. And to make the bindings useful, you must build them. > > > >Dan > > > > > > > > > but what about a %with_mono flag in the spec file which lets us build it > without using third party packages? like its done with the bytecode > interpreter in freetype. (or the ntfs kernel module but this is > something different) This is kind of what I was talking about. So Red Hat, Inc. would not enable this flag in their build, but a Mono fan, would rebuild the rpm with that flag enabled. NRPMS.net have their own FC4 rpms for the necessary packages. I'm guessing they have their %with_mono flag in their specs. Benjy -------------- next part -------------- An HTML attachment was scrubbed... URL: From tromey at redhat.com Thu Dec 15 17:01:25 2005 From: tromey at redhat.com (Tom Tromey) Date: 15 Dec 2005 10:01:25 -0700 Subject: rawhide report: 20051215 changes In-Reply-To: <1134666176.29159.3.camel@tophat.toronto.redhat.com> References: <200512150831.jBF8ViBr023647@porkchop.devel.redhat.com> <1134659771.4124.100.camel@T7.Linux> <1134666176.29159.3.camel@tophat.toronto.redhat.com> Message-ID: >>>>> "Andrew" == Andrew Overholt writes: Andrew> I've been trying to get Eclipse to build for a few days now. There was Andrew> a gcc bug which got fixed yesterday by Andrew Haley but today I'm Andrew> running into Andrew> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175833 I think this failure occurs due to a buglet in the recent fix for gcc PR 25429. See: http://gcc.gnu.org/ml/java-patches/2005-q4/msg00342.html Tom From ph18 at cornell.edu Thu Dec 15 17:27:30 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Thu, 15 Dec 2005 12:27:30 -0500 Subject: Fedora meeting Mono Half-Way In-Reply-To: References: <43A155CF.4000500@3di.it> <43A1961F.8060706@cornell.edu> Message-ID: <43A1A782.8000506@cornell.edu> Gianluca Sforna wrote: > Despite I know _zero_ C#, your list list seems to be quite fulfilled > by C++ (or, if you want to stick to higher level languages, python). I > guess Peter's answer should be nearer to reality... > Yeah, and you've got to get a PhD in C++ to just write "hello world". When Owen Taylor was a physics grad student, I looked over his shoulder at screens of immaculate pseudo-OO C that he'd write and he talked my ear off about what was wrong with C++. This is why the gtk C++ bindings are called gtk--. Sure, you can find C++ libraries for automatically managed objects, safe strings, and wonderful data structures. Boost, for instance, is wonderful, but I can't get it compiled on a number of older Linux and Solaris servers that don't have gcc 4. For 20 years people have been inventing and re-inventing the wheel for doing basic things in C++, so C++ code bases are painfully fragmented. As for Python, the Python community makes fantastic claims about rapid development in Python. So far as I can tell, the idea is that you can get your application working 80% for 20% of the work, so let's just do 20% of the work and say it's done. Python has the same thread safety problems as PHP and Perl (it links in who knows how many unsafe libraries) but the Python people tell you to jump right in and use threads, whereas the PHP and Perl people warn about the dangers. In another thread, people are talking about the Python bittorrent client -- which wouldn't run on FC3 a year ago because Python broke a bunch of API's. And don't get me started about all the GUI gadgets in FC and RHEL written in Python that "almost work"... These things don't bother me since I just edit /etc/sysconfig, but they certainly make Linux look bad in the eyes of novices. From davej at redhat.com Thu Dec 15 17:32:12 2005 From: davej at redhat.com (Dave Jones) Date: Thu, 15 Dec 2005 12:32:12 -0500 Subject: libusual interface [was Re: libusual and ub] In-Reply-To: <1134655233.2864.31.camel@bree.local.net> References: <20051029193544.096d400e.zaitcev@redhat.com> <20051215031822.GA12020@devserv.devel.redhat.com> <20051214211008.22c1ae47.zaitcev@redhat.com> <20051215053741.GA13787@devserv.devel.redhat.com> <20051215002129.4e9863e0.zaitcev@redhat.com> <1134655233.2864.31.camel@bree.local.net> Message-ID: <20051215173212.GB19354@redhat.com> On Thu, Dec 15, 2005 at 09:00:33AM -0500, Jeremy Katz wrote: > With libusual built-in as davej currently has it, it becomes a little > bit harder because we don't want to rely on people passing kernel > arguments I've no objection to changing this to be modular if needed. Dave From alan at redhat.com Thu Dec 15 17:35:31 2005 From: alan at redhat.com (Alan Cox) Date: Thu, 15 Dec 2005 12:35:31 -0500 Subject: Fedora meeting Mono Half-Way In-Reply-To: <43A1961F.8060706@cornell.edu> References: <43A155CF.4000500@3di.it> <43A1961F.8060706@cornell.edu> Message-ID: <20051215173531.GB9208@devserv.devel.redhat.com> On Thu, Dec 15, 2005 at 11:13:19AM -0500, Paul A Houle wrote: > Automatic memory management, no buffer overflows because the > authors didn't do string handling with superhuman care, OO programming Umm actually thats a very dangerous assumption. If the implementation in mono is wrong then every app in mono has the hole. We've seen this occur historically in other 'safe' languages. Also if there are bugs in libraries it uses they end up everywhere > model where people use objects to model the problem domain rather than > spend 20 years arguing about how to implement a linked list. g_list, g_string and friends already provide that interface set in C and fairly efficiently. Most gnome C apps use them and GNOME has had almost no buffer overrun problems. Lots of other problems but not those. If you don't use the tools properly you don't get good results. Thats nothing to do with mono From sopwith at redhat.com Thu Dec 15 17:36:24 2005 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 15 Dec 2005 12:36:24 -0500 (EST) Subject: Fedora meeting Mono Half-Way In-Reply-To: <43A1A782.8000506@cornell.edu> References: <43A155CF.4000500@3di.it> <43A1961F.8060706@cornell.edu> <43A1A782.8000506@cornell.edu> Message-ID: On Thu, 15 Dec 2005, Paul A Houle wrote: > Yeah, and you've got to get a PhD in C++ to just write "hello > world". When Owen Taylor was a physics grad student, I looked over his > shoulder at screens of immaculate pseudo-OO C that he'd write and he > talked my ear off about what was wrong with C++. This is why the gtk > C++ bindings are called gtk--. (Actually, it's because I thought it would make a cute joke... Owen's reported dislike for C++ may have been what led him to avoid ever getting involved with the C++ bindings :) Best, -- Elliot Unanswered questions in The Matrix: What happens if you take both the red pill AND the blue pill? From arjan at fenrus.demon.nl Thu Dec 15 17:44:00 2005 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Thu, 15 Dec 2005 18:44:00 +0100 Subject: Fedora meeting Mono Half-Way In-Reply-To: <20051215173531.GB9208@devserv.devel.redhat.com> References: <43A155CF.4000500@3di.it> <43A1961F.8060706@cornell.edu> <20051215173531.GB9208@devserv.devel.redhat.com> Message-ID: <1134668640.16486.54.camel@laptopd505.fenrus.org> On Thu, 2005-12-15 at 12:35 -0500, Alan Cox wrote: > On Thu, Dec 15, 2005 at 11:13:19AM -0500, Paul A Houle wrote: > > Automatic memory management, no buffer overflows because the > > authors didn't do string handling with superhuman care, OO programming > > Umm actually thats a very dangerous assumption. If the implementation in > mono is wrong then every app in mono has the hole. We've seen this occur > historically in other 'safe' languages. Also if there are bugs in libraries > it uses they end up everywhere > > > model where people use objects to model the problem domain rather than > > spend 20 years arguing about how to implement a linked list. > > g_list, g_string and friends already provide that interface set in C and > fairly efficiently. Most gnome C apps use them and GNOME has had almost no > buffer overrun problems. Lots of other problems but not those. in addition the execshield tech (gcc/glibc/kernel) makes buffer overflows basically impossible to abuse anyway (like -fstack-protector, FORTIFY_SOURCE, NX, randomisation etc etc) From green at redhat.com Thu Dec 15 17:46:44 2005 From: green at redhat.com (Anthony Green) Date: Thu, 15 Dec 2005 09:46:44 -0800 Subject: bittorrent in core? what frontend? In-Reply-To: <40142.10.10.10.28.1134664763.squirrel@linux1> References: <1134662961.28842.128.camel@greebo> <40142.10.10.10.28.1134664763.squirrel@linux1> Message-ID: <1134668805.3312.33.camel@localhost.localdomain> On Thu, 2005-12-15 at 11:39 -0500, Sean wrote: > On Thu, December 15, 2005 11:09 am, Alexander Larsson said: > > > I don't use bittorrent all that much. What do people think about these > > two frontends? Are there other interesting ones? > > Azureus is really the best. Just did a quick google to see if gcj 4.1 > can compile it, and sure enough Slashdot says it works, so it must be true > ;) Last I tried it almost worked... http://spindazzle.org/pics/azureus-on-gcj4-2004-12-9.png I will give it another go once a gcj4.1 built SWT (from Eclipse) lands in rawhide. There have been many Classpath bug fixes over the past year, so everybody cross your fingers. AG From dcbw at redhat.com Thu Dec 15 17:46:19 2005 From: dcbw at redhat.com (Dan Williams) Date: Thu, 15 Dec 2005 12:46:19 -0500 Subject: Fedora meeting Mono Half-Way In-Reply-To: <43A1A782.8000506@cornell.edu> References: <43A155CF.4000500@3di.it> <43A1961F.8060706@cornell.edu> <43A1A782.8000506@cornell.edu> Message-ID: <1134668780.2869.10.camel@localhost.localdomain> On Thu, 2005-12-15 at 12:27 -0500, Paul A Houle wrote: > just do 20% of the work and say it's done. Python has the same thread > safety problems as PHP and Perl (it links in who knows how many unsafe > libraries) but the Python people tell you to jump right in and use > threads, whereas the PHP and Perl people warn about the dangers. In The Fedora Extras build system is written in Python, from the server to client to the web interface. It makes _heavy_ use of threads. The hardest problem in Python with threads is making sure all your python imports are threadsafe. pyOpenSSL was not threadsafe when I began plague, but fixing that issue was simple even if the diagnosis was long & arduous. Now that pyOpenSSL threading is OK, the build system code works fine. The point here being that Python's thread safety and behavior when running 10s or even 100s of threads is actually quite good in base Python (since 2.4). Since python pretty much just uses libraries that are on the system anyway (eg libxml, OpenSSL, etc), you'd have have to make those libraries thread-safe or protect your usage of them if you used C/C++ anyway. It's not a problem specific to Python or Perl or PHP. GUI apps don't count, because almost all toolkits (win32, Cocoa/Carbon, GTK+) are explicitly _not_ threadsafe, though they may be thread-aware and contain workarounds for threading. You can't, for example, run Cocoa GUI code from the thread that doesn't own the Cocoa event loop. Same thing for GTK+; you shouldn't modify widgets from a different thread than the mainloop is running in. That's why there's so much focus on MVC and messages; separate the View from the data model, and you're fine. Dan From ph18 at cornell.edu Thu Dec 15 18:04:32 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Thu, 15 Dec 2005 13:04:32 -0500 Subject: Fedora meeting Mono Half-Way In-Reply-To: <20051215173531.GB9208@devserv.devel.redhat.com> References: <43A155CF.4000500@3di.it> <43A1961F.8060706@cornell.edu> <20051215173531.GB9208@devserv.devel.redhat.com> Message-ID: <43A1B030.9030406@cornell.edu> Alan Cox wrote: > Umm actually thats a very dangerous assumption. If the implementation in > mono is wrong then every app in mono has the hole. We've seen this occur > historically in other 'safe' languages. Also if there are bugs in libraries > it uses they end up everywhere > > Yeah, but if you find a bug in mono, java, python or some other runtime you can patch it -- it's much less work than auditing the use of strings and pointers in each applications. As for library bugs, that's an area where Java does better than C#. Half of it is that JNI is painful enough that people don't want to use it, the other half is that "100% Pure Java" has encouraged a kind of xenophobia -- rather than import thousands of libraries that aren't thread-safe, the culture of Java is such that people have started in a greenfield where, at the least, people were warned that their applications would live in a threaded environment. C# was designed to make it easy to use legacy libraries. Pandering to lazy programmers is the Microsoft Way. C# is less (security, pointer goofs, memory leaks, thread) safe than Java as a result. > If you don't use the tools properly you don't get good results. Thats > nothing to do with mono Yeah, but some tools are hard to use properly. People have been writing C for 30 years, and most still don't get it right. A lot of programmers aren't happy with the options available for writing Gnome apps, and this is one reason why some respected Gnomers have gone down the mono path. I totally agree that mono is in a legal minefield, and I respect the decision to not carry it. In a lot of ways, Red Hat's hands are tied. Maybe we need really good Gnome bindings that work for Java/gcj... I used to be skeptical about Java on the desktop, but Azureus has made me a believer... It "just works" on Windows, Linux and Mac OS X. Speed, reliability and features compare favorably with native apps. Every so often I think about learning how to program desktop apps, but now that we've got AJAX and the Canvas element, I can do the things I want to do with web apps. The desktop app situation on Unix (never mind cross-platform) is a real mess. I regularly end up spending hours tracking down and installing libraries when I want to install a GUI app on Solaris or older Red Hat system. If I target the web platform, my app works on all the computers I use without the fuss... From brugolsky at telemetry-investments.com Thu Dec 15 18:10:39 2005 From: brugolsky at telemetry-investments.com (Bill Rugolsky Jr.) Date: Thu, 15 Dec 2005 13:10:39 -0500 Subject: funny user moment (and perhaps a bug) In-Reply-To: <43A19EB1.6030608@redhat.com> References: <1134582427.30388.4.camel@willow.odshp.com> <12349.202.12.233.21.1134599074.squirrel@server.twofifty.bpa.nu> <1134632869.7509.10.camel@hamburger.booze> <1134652051.2968.6.camel@localhost.localdomain> <1134654876.4464.22.camel@brilong-lnx> <1134656478.4766.1.camel@localhost.localdomain> <20051215143128.GD31269@ti64.telemetry-investments.com> <43A19EB1.6030608@redhat.com> Message-ID: <20051215181039.GB4538@ti64.telemetry-investments.com> On Thu, Dec 15, 2005 at 10:19:53PM +0530, Rahul Sundaram wrote: > >Given the proliferation of session daemons, perhaps the right answer is for > >people who need this to use Linux-Vserver or OpenVZ to provide isolation > >similar to running on separate machines with a network share. > > > > > Unless these patches get upstream, they are not the right answer - > atleast for Fedora. Oh, I certainly agree; my point is that for someone who *really* needs this capability, rather than just "oh that would be nice and clean...", there is a route available. Just as audio workstation users take Fedora Core and transform it into PlanetCCRMA by running adding a bunch of packages and running a custom Ingo-turbocharged RT kernel. In both case, the stuff might make it upstream one day, or might not. Xen provides an interesting example too. Over the years there have been dozens of checkpoint/migrate/restart mechanisms developed at the process level, and they are complicated beasts. With Xen, the unit of encapsulation is the OS instance, and a non-local filesystem and gratuitous ARP are about all that's required. -Bill From johnp at redhat.com Thu Dec 15 18:23:32 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Thu, 15 Dec 2005 13:23:32 -0500 Subject: bittorrent in core? what frontend? In-Reply-To: <43A19DAF.6050407@insitesinc.com> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> Message-ID: <1134671012.12010.134.camel@remedyz.boston.redhat.com> On Thu, 2005-12-15 at 10:45 -0600, Michael Favia wrote: > Luke Macken wrote: > > > > If any bittorrent client is to slip into core, my vote is for the > > upstream default. > > > > | I think the only viable alternative would be azureus really, which is > > | java-based. > > > > Azureus is OK, but is a bit feature-bloated IMO for a pice of software > > that just needs to manage downloads (I mean, seriously, do people really > > need an IRC client built into their bittorrent client?). I think that > > the functionality of the standard upstream gui should satisfy all of our > > core needs. > Agreed about the IRC client but does it allow bandwidth throttling, file > priority selection (High, low, dont get), and UPnP router management? > I haven't used it because azureus has satisfied all my needs just > wondering what it provided and that rpm looks so far away. -mf Not sure but I think the one in core should be the simplest. Click on a .torrent file and a nice little progress bar pops up to tell you the status and perhaps sits in the notification area. By all means though, get Azureus to work and find someone to package it into extras. -- John (J5) Palmieri From pjones at redhat.com Thu Dec 15 18:33:47 2005 From: pjones at redhat.com (Peter Jones) Date: Thu, 15 Dec 2005 13:33:47 -0500 Subject: funny user moment (and perhaps a bug) In-Reply-To: <1134663626.17385.139.camel@localhost.localdomain> References: <1134582427.30388.4.camel@willow.odshp.com> <12349.202.12.233.21.1134599074.squirrel@server.twofifty.bpa.nu> <1134632869.7509.10.camel@hamburger.booze> <1134652051.2968.6.camel@localhost.localdomain> <1134653825.30243.146.camel@mccallum.corsepiu.local> <1134663626.17385.139.camel@localhost.localdomain> Message-ID: <1134671628.10606.18.camel@localhost.localdomain> On Thu, 2005-12-15 at 08:20 -0800, Per Bjornsson wrote: > On Thu, 2005-12-15 at 14:37 +0100, Ralf Corsepius wrote: > > > Standard situations: > > * You login into your personal "desktop" in your office, and leave for > > another room, on the same network and want to login there ... > > * Several monitors on your desktop physically connected to different > > machines, but with a common and shared (networked) /home underneath. > > Actually that is very different from logging in several times on the > same machine. (Unless you use LTSP I guess, but that's not what you > said.) It's very similar to XDMCP from another box, which _is_ logging on to the machine twice. -- Peter From jspaleta at gmail.com Thu Dec 15 18:33:51 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 15 Dec 2005 13:33:51 -0500 Subject: bittorrent in core? what frontend? In-Reply-To: <1134671012.12010.134.camel@remedyz.boston.redhat.com> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> Message-ID: <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> On 12/15/05, John (J5) Palmieri wrote: > Not sure but I think the one in core should be the simplest. Click on > a .torrent file and a nice little progress bar pops up to tell you the > status and perhaps sits in the notification area. I think notification area item is going to be pretty important. Isn't the whole point of a bittorrent client to act as a peer even when the download is completed? If all people are doing is leeching and then turning off their own torrent nodes that sort of defeats the purpose of the peering concept. I think you'll definitely want to continue to inform the desktop user that the bittorrent node is still active and is uploading to other peers aftger the download is complete. I don't think you want that going on in the background without some visual que to remind people. -jef From pjones at redhat.com Thu Dec 15 18:38:00 2005 From: pjones at redhat.com (Peter Jones) Date: Thu, 15 Dec 2005 13:38:00 -0500 Subject: Fedora meeting Mono Half-Way In-Reply-To: References: <43A155CF.4000500@3di.it> Message-ID: <1134671880.10606.21.camel@localhost.localdomain> On Thu, 2005-12-15 at 07:27 -0500, Benjy Grogan wrote: > I know. I'm saying forget about Mono. Just install the mono bindings > for d-bus, hal, etc... there are no patent issues with them. You have to have mono installed to build the bindings. One requirement for Fedora Core is that it must be self hosting. So we can't do that unless we're including mono. -- Peter From pjones at redhat.com Thu Dec 15 18:45:09 2005 From: pjones at redhat.com (Peter Jones) Date: Thu, 15 Dec 2005 13:45:09 -0500 Subject: Fedora meeting Mono Half-Way In-Reply-To: <1134668640.16486.54.camel@laptopd505.fenrus.org> References: <43A155CF.4000500@3di.it> <43A1961F.8060706@cornell.edu> <20051215173531.GB9208@devserv.devel.redhat.com> <1134668640.16486.54.camel@laptopd505.fenrus.org> Message-ID: <1134672310.10606.26.camel@localhost.localdomain> On Thu, 2005-12-15 at 18:44 +0100, Arjan van de Ven wrote: > > g_list, g_string and friends already provide that interface set in C and > > fairly efficiently. Most gnome C apps use them and GNOME has had almost no > > buffer overrun problems. Lots of other problems but not those. > > in addition the execshield tech (gcc/glibc/kernel) makes buffer > overflows basically impossible to abuse anyway (like -fstack-protector, > FORTIFY_SOURCE, NX, randomisation etc etc) That's true, and while I love the enhanced security we get from this, it kind of ignores the bigger picture. Detecting faults better and crashing in a way that's not exploitable does nothing to address usability or stability. A crashing program is still catastrophic for users, even if it's no longer a root exploit. -- Peter From michael.favia at insitesinc.com Thu Dec 15 18:45:17 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Thu, 15 Dec 2005 12:45:17 -0600 Subject: bittorrent in core? what frontend? In-Reply-To: <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> Message-ID: <43A1B9BD.2080306@insitesinc.com> Jeff Spaleta wrote: > On 12/15/05, John (J5) Palmieri wrote: >> Not sure but I think the one in core should be the simplest. Click on >> a .torrent file and a nice little progress bar pops up to tell you the >> status and perhaps sits in the notification area. > > I think notification area item is going to be pretty important. Isn't > the whole point of a bittorrent client to act as a peer even when the > download is completed? If all people are doing is leeching and then > turning off their own torrent nodes that sort of defeats the purpose > of the peering concept. I think you'll definitely want to continue to > inform the desktop user that the bittorrent node is still active and > is uploading to other peers aftger the download is complete. I don't > think you want that going on in the background without some visual que > to remind people. While i agree with j5 statemnt on simplicity i disagree that closing the torrent "defeats" the purpose. Even if individuals close the torrent after download they still supported the torrent throughout their download. (even if U/D ratios are biased). While it's only decent to wait till you have a 1:1 ratio imo it is perfectly acceptable to get what you need and mosey on if you'd like. A way to tell users about reaching 1:1 or any predefined ration in the systray would be appreciated though. -mf From tromey at redhat.com Thu Dec 15 19:02:04 2005 From: tromey at redhat.com (Tom Tromey) Date: 15 Dec 2005 12:02:04 -0700 Subject: Fedora meeting Mono Half-Way In-Reply-To: <43A1B030.9030406@cornell.edu> References: <43A155CF.4000500@3di.it> <43A1961F.8060706@cornell.edu> <20051215173531.GB9208@devserv.devel.redhat.com> <43A1B030.9030406@cornell.edu> Message-ID: >>>>> "Paul" == Paul A Houle writes: Paul> Maybe we need really good Gnome bindings that work for Java/gcj... If java-gnome isn't good somehow, I'm sure bug reports are helpful... :-) Also, chances are you could translate Beagle to java without much difficulty. SMOP and all that. Tom From jspaleta at gmail.com Thu Dec 15 19:11:43 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 15 Dec 2005 14:11:43 -0500 Subject: bittorrent in core? what frontend? In-Reply-To: <43A1B9BD.2080306@insitesinc.com> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A1B9BD.2080306@insitesinc.com> Message-ID: <604aa7910512151111m60fc319apbff42f35dbe1a665@mail.gmail.com> On 12/15/05, Michael Favia wrote: > Jeff Spaleta wrote: > While i agree with j5 statemnt on simplicity i disagree that closing the > torrent "defeats" the purpose. Even if individuals close the torrent > after download they still supported the torrent throughout their > download. I have no problem letting users choose to stop their local bittorrent node whenever they wish. What I have a problem with is a default application that shutdowns the node activity at the end of downloads by default for everyone... pretending to be something like an http or ftp download client. The peer activity of the bittorrent process is important and i think it needs to be clear in the UI that uploads are happening and can continue to happen as long as the local bittorrent client stays alive. I think its a bastardization of the bittorrent concept to have the default client in Core that people will reach for be so simple as to shutdown upload activity at the end of download activity without making an effort to educate the user that bittorent is a peer process and gives the user the choice to turn off the upload activity or leave it running. A notification area icon which uses the libnotify bubbly crap seems most appropriate to me. -jef From johnp at redhat.com Thu Dec 15 19:29:57 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Thu, 15 Dec 2005 14:29:57 -0500 Subject: bittorrent in core? what frontend? In-Reply-To: <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> Message-ID: <1134674997.12010.149.camel@remedyz.boston.redhat.com> You misinterpreted what I was saying. Gaim is the best example here. Start it up and an icon appears in the notification area which is persistent until you exit gaim. But that is just a thought and not indicative of what we are trying to choose here, which is out of teh existing GUI's which one do we pick. I'm just saying as long as the client gives feedback and is launched when clicking on a torrent file, pick the simplest one out there as the default. On Thu, 2005-12-15 at 13:33 -0500, Jeff Spaleta wrote: > On 12/15/05, John (J5) Palmieri wrote: > > Not sure but I think the one in core should be the simplest. Click on > > a .torrent file and a nice little progress bar pops up to tell you the > > status and perhaps sits in the notification area. > > I think notification area item is going to be pretty important. Isn't > the whole point of a bittorrent client to act as a peer even when the > download is completed? If all people are doing is leeching and then > turning off their own torrent nodes that sort of defeats the purpose > of the peering concept. I think you'll definitely want to continue to > inform the desktop user that the bittorrent node is still active and > is uploading to other peers aftger the download is complete. I don't > think you want that going on in the background without some visual que > to remind people. > > -jef -- John (J5) Palmieri From jdesbonnet at gmail.com Thu Dec 15 19:38:34 2005 From: jdesbonnet at gmail.com (Joe Desbonnet) Date: Thu, 15 Dec 2005 19:38:34 +0000 Subject: Fedora meeting Mono Half-Way In-Reply-To: <43A1B030.9030406@cornell.edu> References: <43A155CF.4000500@3di.it> <43A1961F.8060706@cornell.edu> <20051215173531.GB9208@devserv.devel.redhat.com> <43A1B030.9030406@cornell.edu> Message-ID: <1cef3e950512151138x7bd511a4u817a201270a05b5d@mail.gmail.com> I agree -- using a webapp approach to the desktop will prove far more productive. You get nice clean separation between GUI and the logic and it's (IMHO) far, far easier to develop nice GUIs that the traditional C++ approach. BTW -- related question: has Webmin ( http://www.webmin.com/ ) ever been considered as a administration user interface for Fedora? Joe. On 12/15/05, Paul A Houle wrote: > Every so often I think about learning how to program desktop apps, > but now that we've got AJAX and the Canvas element, I can do the > things I want to do with web apps. The desktop app situation on Unix > (never mind cross-platform) is a real mess. I regularly end up spending > hours tracking down and installing libraries when I want to install a > GUI app on Solaris or older Red Hat system. If I target the web > platform, my app works on all the computers I use without the fuss... > From sundaram at redhat.com Thu Dec 15 19:45:47 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 16 Dec 2005 01:15:47 +0530 Subject: Fedora meeting Mono Half-Way In-Reply-To: <1cef3e950512151138x7bd511a4u817a201270a05b5d@mail.gmail.com> References: <43A155CF.4000500@3di.it> <43A1961F.8060706@cornell.edu> <20051215173531.GB9208@devserv.devel.redhat.com> <43A1B030.9030406@cornell.edu> <1cef3e950512151138x7bd511a4u817a201270a05b5d@mail.gmail.com> Message-ID: <43A1C7EB.5040204@redhat.com> Joe Desbonnet wrote: >I agree -- using a webapp approach to the desktop will prove far more >productive. You get nice clean separation between GUI and the logic >and it's (IMHO) far, far easier to develop nice GUIs that the >traditional C++ approach. > >BTW -- related question: has Webmin ( http://www.webmin.com/ ) ever >been considered as a administration user interface for Fedora? > > It has been in the Fedora Extras wishlist for a while. Notes say that there are security concerns with it http://fedoraproject.org/wiki/Extras/ I guess You can still package it if you want to maintain it with a extra eye on security notifications. regards Rahul From johnp at redhat.com Thu Dec 15 19:46:21 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Thu, 15 Dec 2005 14:46:21 -0500 Subject: Fedora meeting Mono Half-Way In-Reply-To: References: <43A155CF.4000500@3di.it> Message-ID: <1134675981.12010.158.camel@remedyz.boston.redhat.com> On Thu, 2005-12-15 at 07:27 -0500, Benjy Grogan wrote: > > > > > I know. I'm saying forget about Mono. Just install the mono bindings > for d-bus, hal, etc... there are no patent issues with them. As the D-Bus co-maintainer and coauthor of the python bindings I can confidently say why would you want this? Packagers don't have to mess with the system libraries. Why? Because they can just package up the bindings. Forget that it all comes from the same source tree. That is not important. P.S. I don't know of any Hal bindings other than the C convenience libraries as you usually access HAL directly from D-Bus for the most part. -- John (J5) Palmieri From johnp at redhat.com Thu Dec 15 19:55:07 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Thu, 15 Dec 2005 14:55:07 -0500 Subject: Fedora meeting Mono Half-Way In-Reply-To: <1134675981.12010.158.camel@remedyz.boston.redhat.com> References: <43A155CF.4000500@3di.it> <1134675981.12010.158.camel@remedyz.boston.redhat.com> Message-ID: <1134676507.12010.160.camel@remedyz.boston.redhat.com> On Thu, 2005-12-15 at 14:46 -0500, John (J5) Palmieri wrote: > On Thu, 2005-12-15 at 07:27 -0500, Benjy Grogan wrote: > > > > > > > > > > > I know. I'm saying forget about Mono. Just install the mono bindings > > for d-bus, hal, etc... there are no patent issues with them. > > As the D-Bus co-maintainer and coauthor of the python bindings I can > confidently say why would you want this? Packagers don't have to mess > with the system libraries. Why? Because they can just package up the > bindings. Forget that it all comes from the same source tree. That is > not important. > > P.S. I don't know of any Hal bindings other than the C convenience > libraries as you usually access HAL directly from D-Bus for the most > part. > > -- > John (J5) Palmieri I should also note that once we stabilize our ABI's you wouldn't even need to update the bindings if the core libraries were updated except to get new functionality. -- John (J5) Palmieri From lmacken at redhat.com Thu Dec 15 20:02:05 2005 From: lmacken at redhat.com (Luke Macken) Date: Thu, 15 Dec 2005 15:02:05 -0500 Subject: bittorrent in core? what frontend? In-Reply-To: <604aa7910512151111m60fc319apbff42f35dbe1a665@mail.gmail.com> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A1B9BD.2080306@insitesinc.com> <604aa7910512151111m60fc319apbff42f35dbe1a665@mail.gmail.com> Message-ID: <20051215200205.GC9717@tomservo.boston.redhat.com> On Thu, Dec 15, 2005 at 02:11:43PM -0500, Jeff Spaleta wrote: | On 12/15/05, Michael Favia wrote: | > Jeff Spaleta wrote: | > While i agree with j5 statemnt on simplicity i disagree that closing the | > torrent "defeats" the purpose. Even if individuals close the torrent | > after download they still supported the torrent throughout their | > download. | | I have no problem letting users choose to stop their local bittorrent | node whenever they wish. I think this is absolutely necessary. Bittorrent has the power to saturate a network real quick, and the last thing we want is a client that could potentially sit in the background behind peoples back un-noticed eating bandwidth just because we think keeping a 1:1 ratio is The Right Thing. This is where a slick notification applet would come in handy. | What I have a problem with is a default | application that shutdowns the node activity at the end of downloads | by default for everyone... pretending to be something like an http or | ftp download client. The peer activity of the bittorrent process is | important and i think it needs to be clear in the UI that uploads are | happening and can continue to happen as long as the local bittorrent | client stays alive. The default gui client has sane post-completion seeding settings, so it doesn't end the seed when the download is finished. | I think its a bastardization of the bittorrent concept to have the | default client in Core that people will reach for be so simple as to | shutdown upload activity at the end of download activity without | making an effort to educate the user that bittorent is a peer process | and gives the user the choice to turn off the upload activity or leave | it running. A notification area icon which uses the libnotify bubbly | crap seems most appropriate to me. I agree. luke From notting at redhat.com Thu Dec 15 20:21:26 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 15 Dec 2005 15:21:26 -0500 Subject: bittorrent in core? what frontend? In-Reply-To: <1134662961.28842.128.camel@greebo> References: <1134662961.28842.128.camel@greebo> Message-ID: <20051215202126.GA4210@devserv.devel.redhat.com> Alexander Larsson (alexl at redhat.com) said: > Another question is what frontend to use as a default. bittorrent itself > ships with a wxPython based frontend (bittorrent-gui, availible with > bittorrent in fedora extras). Another frontend is gnome-bt > (http://gnome-bt.sourceforge.net/) which is designed more like a simple > *.torrent mime handler rather than a full bittorrent app. Ubuntu > defaults to this i think. > > I packaged gnome-bt at: > http://people.redhat.com/alexl/files/gnome-bt-0.0.22-1.noarch.rpm > http://people.redhat.com/alexl/files/gnome-bt-0.0.22-1.src.rpm > > I don't use bittorrent all that much. What do people think about these > two frontends? Are there other interesting ones? I kept meaning to package gnome-bt for Extras, and kept forgetting. So that would be my preference. :) Bill From seg at haxxed.com Thu Dec 15 20:55:14 2005 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 15 Dec 2005 14:55:14 -0600 Subject: Fedora meeting Mono Half-Way In-Reply-To: <43A1B030.9030406@cornell.edu> References: <43A155CF.4000500@3di.it> <43A1961F.8060706@cornell.edu> <20051215173531.GB9208@devserv.devel.redhat.com> <43A1B030.9030406@cornell.edu> Message-ID: <1134680116.7509.16.camel@hamburger.booze> > I used to be skeptical about Java on the desktop, but Azureus has > made me a believer... It "just works" on Windows, Linux and Mac OS X. > Speed, reliability and features compare favorably with native apps. PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 15520 seg 16 1 432m 116m 6616 S 5.0 23.2 374:27.73 java ^^^^ :( (Though admittedly this is with Sun's JRE. Can gcj do any better? Can we get native Azureus yet?) -------------- 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 ihok at hotmail.com Thu Dec 15 20:57:27 2005 From: ihok at hotmail.com (Jack Tanner) Date: Thu, 15 Dec 2005 15:57:27 -0500 Subject: funny user moment (and perhaps a bug) In-Reply-To: <1134652051.2968.6.camel@localhost.localdomain> References: <1134582427.30388.4.camel@willow.odshp.com> <12349.202.12.233.21.1134599074.squirrel@server.twofifty.bpa.nu> <1134632869.7509.10.camel@hamburger.booze> <1134652051.2968.6.camel@localhost.localdomain> Message-ID: Dan Williams wrote: > Hmm, what the heck for? That's what Desktop->Preferences->Remote > Desktop is for, really. What's the case for logging in twice? Shell > and desktop are so totally different that I'm not convinced that they > should operate the same way here (not that my opinion matters, really). > Should we expect all applications that provide GUI to put in a ton of > work to account for a case that a fairly small number of people might > actually use? Wow. I had no idea that this would be controversial. Yes, sometimes I log into Gnome twice as the same user on the same machine. For example, my FC4 box has a CD burner; my Windows box doesn't. But, my Windows box has a nicer monitor than the FC4 box. So, I log into the FC4 box locally, and do the CD burning dance on that machine. At the same time, I sit at my Windows box, log into the FC4 box via NX, and run other user apps (Thunderbird, etc.) It seemed completely natural to me to use my desktop that way. From seg at haxxed.com Thu Dec 15 21:11:55 2005 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 15 Dec 2005 15:11:55 -0600 Subject: bittorrent in core? what frontend? In-Reply-To: <43A19818.7090402@insitesinc.com> References: <1134662961.28842.128.camel@greebo> <43A19818.7090402@insitesinc.com> Message-ID: <1134681116.7509.25.camel@hamburger.booze> Err, Azureus is nice, I use it myself, but its squarely a super-ultra-mega power user application, I'd hesitate to set it up as a Fedora default. -------------- 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 ihok at hotmail.com Thu Dec 15 21:06:49 2005 From: ihok at hotmail.com (Jack Tanner) Date: Thu, 15 Dec 2005 16:06:49 -0500 Subject: funny user moment (and perhaps a bug) In-Reply-To: <604aa7910512131458o444fd787o73302d58233da713@mail.gmail.com> References: <604aa7910512131458o444fd787o73302d58233da713@mail.gmail.com> Message-ID: Jeff Spaleta wrote: > If there is a bug here it probably has to do with the fact that the > cd-player application itself gets out of sync across multiple > invocations. Can you reproduce this by starting 2 gnome-cd instances > in the same gnome session? Yes. 1. Starting 1 gnome-cd instance, play the CD. 2. Start another gnome-cd. It won't catch that the CD is playing. From ihok at hotmail.com Thu Dec 15 21:23:55 2005 From: ihok at hotmail.com (Jack Tanner) Date: Thu, 15 Dec 2005 16:23:55 -0500 Subject: bittorrent in core? what frontend? In-Reply-To: <1134671012.12010.134.camel@remedyz.boston.redhat.com> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> Message-ID: John (J5) Palmieri wrote: > Not sure but I think the one in core should be the simplest. Click on > a .torrent file and a nice little progress bar pops up to tell you the > status and perhaps sits in the notification area. By all means though, > get Azureus to work and find someone to package it into extras. I don't mean to get into "my favorite client is X" debate, but if we're picking something for core, I'd argue for picking a client that people really love.[1] I've never used Azureus, but by that reasoning, since Azureus is regularly on sf.net's most downloaded/highest activity lists, it's a good choice. The "safe but boring" default client is a bad choice. [1] http://headrush.typepad.com/creating_passionate_users/2005/12/being_brave_is_.html From ph18 at cornell.edu Thu Dec 15 21:44:12 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Thu, 15 Dec 2005 16:44:12 -0500 Subject: Fedora meeting Mono Half-Way In-Reply-To: <1134680116.7509.16.camel@hamburger.booze> References: <43A155CF.4000500@3di.it> <43A1961F.8060706@cornell.edu> <20051215173531.GB9208@devserv.devel.redhat.com> <43A1B030.9030406@cornell.edu> <1134680116.7509.16.camel@hamburger.booze> Message-ID: <43A1E3AC.5020300@cornell.edu> Callum Lerwick wrote: >> I used to be skeptical about Java on the desktop, but Azureus has >> made me a believer... It "just works" on Windows, Linux and Mac OS X. >> Speed, reliability and features compare favorably with native apps. >> > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > 15520 seg 16 1 432m 116m 6616 S 5.0 23.2 374:27.73 java > ^^^^ > :( > Yeah, that's what it says on paper. You'll often find people who have horrible back pain, but the CAT scan looks normal, and you'll see people who look like they couldn't walk who are champion Olympic lifters. In practice I've run it on a number of machines between 384M-512M of RAM and it's always been fine, even doing other things in the background. It could be that the actual working set is much smaller than 432M, and the rest gets swapped out w/o any suffering. From tmus at tmus.dk Thu Dec 15 21:42:30 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Thu, 15 Dec 2005 22:42:30 +0100 Subject: "yum --partial" feature as a bash line In-Reply-To: <1134517049.28114.65.camel@willow.odshp.com> References: <439C0C8A.9090002@interia.pl> <1134517049.28114.65.camel@willow.odshp.com> Message-ID: Wil Cooley wrote: > On Sun, 2005-12-11 at 12:24 +0100, cybernet at interia.pl wrote: > >> # get a list of items >> # remove 4 lines from top (tac/head/tac) >> # try to update one item at a time >> for k in `yum list updates | awk '{ print $1 }' | tac | head -n-4 | >> tac`; do yum -y update >> $k; done > > UUOTac? Try "sed '1,4d'" instead of the tac|head|tac stuff. Or better, > use an awk range to filter the output: > > awk '/^Setting up/,/^Updated Packages/{next};{print $1}' > > Although this might be better, because it could be used with '-e 0 -d 0' > consistently: > > awk 'FNR==1,/^Updated Packages/ {next}; {print}' > > Wil > The problem with any of these are that long package names gets mangled in the yum output and i haven't found a place to tweak that. /Thomas From skvidal at phy.duke.edu Thu Dec 15 21:51:01 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 15 Dec 2005 16:51:01 -0500 Subject: "yum --partial" feature as a bash line In-Reply-To: References: <439C0C8A.9090002@interia.pl> <1134517049.28114.65.camel@willow.odshp.com> Message-ID: <1134683461.26513.6.camel@cutter> On Thu, 2005-12-15 at 22:42 +0100, Thomas M Steenholdt wrote: > Wil Cooley wrote: > > On Sun, 2005-12-11 at 12:24 +0100, cybernet at interia.pl wrote: > > > >> # get a list of items > >> # remove 4 lines from top (tac/head/tac) > >> # try to update one item at a time > >> for k in `yum list updates | awk '{ print $1 }' | tac | head -n-4 | > >> tac`; do yum -y update > >> $k; done > > > > UUOTac? Try "sed '1,4d'" instead of the tac|head|tac stuff. Or better, > > use an awk range to filter the output: > > > > awk '/^Setting up/,/^Updated Packages/{next};{print $1}' > > > > Although this might be better, because it could be used with '-e 0 -d 0' > > consistently: > > > > awk 'FNR==1,/^Updated Packages/ {next}; {print}' > > > > Wil > > > > The problem with any of these are that long package names gets mangled > in the yum output and i haven't found a place to tweak that. > an EXCELLENT reason to never rely on screenscraping. -sv From dominik at greysector.net Thu Dec 15 21:59:52 2005 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Thu, 15 Dec 2005 22:59:52 +0100 Subject: kernel-2.6.14-1.1653_FC4.netdev.6? In-Reply-To: <20051215162712.GC16712@redhat.com> References: <43A05044.7060803@cygnusx-1.org> <20051215005152.GF26108@rathann.pekin.waw.pl> <20051215010803.GE9801@redhat.com> <20051215162712.GC16712@redhat.com> Message-ID: <20051215215952.GC4336@rathann.pekin.waw.pl> On Thursday, 15 December 2005 at 17:27, John W. Linville wrote: > On Wed, Dec 14, 2005 at 08:08:03PM -0500, John W. Linville wrote: > > On Thu, Dec 15, 2005 at 01:51:52AM +0100, Dominik 'Rathann' Mierzejewski wrote: > > > On Wednesday, 14 December 2005 at 18:03, Nathan Grennan wrote: > > > > I am interested in moving to kernel-2.6.14-1.1653_FC4, and I am > > > > curious when kernel-2.6.14-1.1653_FC4.netdev.6 will be out. > > > > > > Me too. I'm interested in updated ipw2200 driver in particular. > > > > Workin' on it... > > kernel-2.6.14-1.1653_FC4.netdev.6 is available now: > > http://people.redhat.com/linville/kernels/fedora-netdev/ > > Thanks! Thank you! I'll test and see if I can finally get one Acer Travelmate 8100 running with this. Oh, BTW: any chance of including something like: CONFIG_STANDALONE=n CONFIG_PREVENT_FIRMWARE_BUILD=n CONFIG_ACPI_CUSTOM_DSDT=y CONFIG_ACPI_CUSTOM_DSDT_FILE="/lib/firmware/DSDT.hex" in Fedora kernel config? This Acer has a really broken ACPI DSDT and I wish I didn't have to rebuild every new kernel. Regards, R. -- APT/YUM RPM repository for Fedora Core http://rpm.greysector.net/ mpg321, xmp, faad2, lame, mad, *mplayer*, rdesktop, tin, xvid, mks, mutt "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From sopwith at redhat.com Thu Dec 15 22:00:11 2005 From: sopwith at redhat.com (Elliot Lee) Date: Thu, 15 Dec 2005 17:00:11 -0500 (EST) Subject: Fedora meeting Mono Half-Way In-Reply-To: <43A1E3AC.5020300@cornell.edu> References: <43A155CF.4000500@3di.it> <43A1961F.8060706@cornell.edu> <20051215173531.GB9208@devserv.devel.redhat.com> <43A1B030.9030406@cornell.edu> <1134680116.7509.16.camel@hamburger.booze> <43A1E3AC.5020300@cornell.edu> Message-ID: > Callum Lerwick wrote: > >> I used to be skeptical about Java on the desktop, but Azureus has > >> made me a believer... It "just works" on Windows, Linux and Mac OS X. > >> Speed, reliability and features compare favorably with native apps. > >> > > > > PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND > > 15520 seg 16 1 432m 116m 6616 S 5.0 23.2 374:27.73 java > > ^^^^ > > :( The 'VIRT' number includes all the shared libraries and dynamic objects that are mapped in, even if they have never actually been paged in. Notice how the 'RES'ident memory usage is 116M. Also, this is memory usage with a JVM. In all languages there is a tradeoff between memory usage and execution speed. Native code uses more memory but often runs faster. Interpreted languages use relatively little memory for code, but generally run slower. JVMs generally use about as much memory as native code, and can run nearly as fast. If you use a native compiler like gcj, I'm sure you could get a different result set. Meanwhile, using gij will give you a nice, slow interpreter for Java. :) It's all about making the right tradeoffs... :) Best, -- Elliot Unanswered questions in The Matrix: What happens if you take both the red pill AND the blue pill? From tmus at tmus.dk Thu Dec 15 21:59:36 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Thu, 15 Dec 2005 22:59:36 +0100 Subject: "yum --partial" feature as a bash line In-Reply-To: <1134683461.26513.6.camel@cutter> References: <439C0C8A.9090002@interia.pl> <1134517049.28114.65.camel@willow.odshp.com> <1134683461.26513.6.camel@cutter> Message-ID: seth vidal wrote: > On Thu, 2005-12-15 at 22:42 +0100, Thomas M Steenholdt wrote: >> Wil Cooley wrote: >>> On Sun, 2005-12-11 at 12:24 +0100, cybernet at interia.pl wrote: >>> >>>> # get a list of items >>>> # remove 4 lines from top (tac/head/tac) >>>> # try to update one item at a time >>>> for k in `yum list updates | awk '{ print $1 }' | tac | head -n-4 | >>>> tac`; do yum -y update >>>> $k; done >>> UUOTac? Try "sed '1,4d'" instead of the tac|head|tac stuff. Or better, >>> use an awk range to filter the output: >>> >>> awk '/^Setting up/,/^Updated Packages/{next};{print $1}' >>> >>> Although this might be better, because it could be used with '-e 0 -d 0' >>> consistently: >>> >>> awk 'FNR==1,/^Updated Packages/ {next}; {print}' >>> >>> Wil >>> >> The problem with any of these are that long package names gets mangled >> in the yum output and i haven't found a place to tweak that. >> > > an EXCELLENT reason to never rely on screenscraping. > > -sv > > Agreed! That's why something like this should work closer to yum! /Thomas From tmus at tmus.dk Thu Dec 15 22:08:14 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Thu, 15 Dec 2005 23:08:14 +0100 Subject: mirror synchronization flags? In-Reply-To: <1134621588.22019.45.camel@cutter> References: <1134569858.16389.21.camel@cutter> <1134621588.22019.45.camel@cutter> Message-ID: seth vidal wrote: > > It's a private list for mirror admins only. From the way you were > speaking I thought you were already a mirror admin. > Nope, but that shouldn't keep me from participating? I have a local mirror for all my local clients. > >> 2. I can't imagine this would be a problem for the official mirrors? > > Then you need a better imagination. Thing could be optional and one could choose one of the mirrors that were doing the right thing! /Thomas From johnp at redhat.com Thu Dec 15 22:14:03 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Thu, 15 Dec 2005 17:14:03 -0500 Subject: bittorrent in core? what frontend? In-Reply-To: References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> Message-ID: <1134684843.12010.173.camel@remedyz.boston.redhat.com> On Thu, 2005-12-15 at 16:23 -0500, Jack Tanner wrote: > John (J5) Palmieri wrote: > > Not sure but I think the one in core should be the simplest. Click on > > a .torrent file and a nice little progress bar pops up to tell you the > > status and perhaps sits in the notification area. By all means though, > > get Azureus to work and find someone to package it into extras. > > I don't mean to get into "my favorite client is X" debate, but if we're > picking something for core, I'd argue for picking a client that people > really love.[1] I've never used Azureus, but by that reasoning, since > Azureus is regularly on sf.net's most downloaded/highest activity lists, > it's a good choice. The "safe but boring" default client is a bad choice. > > [1] > http://headrush.typepad.com/creating_passionate_users/2005/12/being_brave_is_.html And what happens when app XYZ becomes the flavor of the month? Remember, not having it as the default doesn't mean it is not there. >From the responses on this thread I would really encourage someone to package Azureus up for extras because people do seem to love it. I can imagine torrents becoming just like regular download. Oh how I would hate it if every time I went to download a new tarball a huge management window would pop up. All I would want is something to tell me it is downloading and notify me when it is finished. -- John (J5) Palmieri From skvidal at phy.duke.edu Thu Dec 15 23:01:35 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 15 Dec 2005 18:01:35 -0500 Subject: "yum --partial" feature as a bash line In-Reply-To: References: <439C0C8A.9090002@interia.pl> <1134517049.28114.65.camel@willow.odshp.com> <1134683461.26513.6.camel@cutter> Message-ID: <1134687695.26513.17.camel@cutter> > Agreed! That's why something like this should work closer to yum! > I've been waiting on someone to try to implement it. no one has stepped up to try. -sv From skvidal at phy.duke.edu Thu Dec 15 23:02:06 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 15 Dec 2005 18:02:06 -0500 Subject: mirror synchronization flags? In-Reply-To: References: <1134569858.16389.21.camel@cutter> <1134621588.22019.45.camel@cutter> Message-ID: <1134687726.26513.19.camel@cutter> On Thu, 2005-12-15 at 23:08 +0100, Thomas M Steenholdt wrote: > seth vidal wrote: > > > > It's a private list for mirror admins only. From the way you were > > speaking I thought you were already a mirror admin. > > > Nope, but that shouldn't keep me from participating? > I have a local mirror for all my local clients. good. > > > >> 2. I can't imagine this would be a problem for the official mirrors? > > > > Then you need a better imagination. > Thing could be optional and one could choose one of the mirrors that > were doing the right thing! riiiiiiiiiiiiiiiiiiiiight. -sv From skvidal at phy.duke.edu Thu Dec 15 23:02:28 2005 From: skvidal at phy.duke.edu (seth vidal) Date: Thu, 15 Dec 2005 18:02:28 -0500 Subject: mirror synchronization flags? In-Reply-To: <1134687726.26513.19.camel@cutter> References: <1134569858.16389.21.camel@cutter> <1134621588.22019.45.camel@cutter> <1134687726.26513.19.camel@cutter> Message-ID: <1134687748.26513.21.camel@cutter> On Thu, 2005-12-15 at 18:02 -0500, seth vidal wrote: > On Thu, 2005-12-15 at 23:08 +0100, Thomas M Steenholdt wrote: > > seth vidal wrote: > > > > > > It's a private list for mirror admins only. From the way you were > > > speaking I thought you were already a mirror admin. > > > > > Nope, but that shouldn't keep me from participating? > > > > > > I have a local mirror for all my local clients. > > good. > > > > > > > >> 2. I can't imagine this would be a problem for the official mirrors? > > > > > > Then you need a better imagination. > > Thing could be optional and one could choose one of the mirrors that > > were doing the right thing! > > riiiiiiiiiiiiiiiiiiiiight. > seriously - go talk to elliot or luke about bouncer. -sv From sundaram at redhat.com Thu Dec 15 23:04:59 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 16 Dec 2005 04:34:59 +0530 Subject: mirror synchronization flags? In-Reply-To: <1134687748.26513.21.camel@cutter> References: <1134569858.16389.21.camel@cutter> <1134621588.22019.45.camel@cutter> <1134687726.26513.19.camel@cutter> <1134687748.26513.21.camel@cutter> Message-ID: <43A1F69B.8030306@redhat.com> Hi > >seriously - go talk to elliot or luke about bouncer. > > >-sv > > > Details on Fedora mirror management at http://fedoraproject.org/wiki/Fedora regards Rahul From seg at haxxed.com Thu Dec 15 23:25:36 2005 From: seg at haxxed.com (Callum Lerwick) Date: Thu, 15 Dec 2005 17:25:36 -0600 Subject: Fedora meeting Mono Half-Way In-Reply-To: References: <43A155CF.4000500@3di.it> <43A1961F.8060706@cornell.edu> <20051215173531.GB9208@devserv.devel.redhat.com> <43A1B030.9030406@cornell.edu> <1134680116.7509.16.camel@hamburger.booze> <43A1E3AC.5020300@cornell.edu> Message-ID: <1134689137.7509.41.camel@hamburger.booze> Perhaps I should have given more context. Top 5 sorted by memory usage: PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 15520 seg 16 1 434m 109m 6608 R 5.3 21.7 388:55.96 java 7509 seg 16 0 238m 77m 12m S 0.0 15.4 12:48.70 evolution 21276 root 15 0 82084 61m 5264 S 3.3 12.1 617:11.21 Xvnc 3486 seg 15 0 141m 56m 18m S 0.0 11.2 12:34.99 galeon 21120 mldonkey 34 19 67980 36m 2200 D 1.0 7.3 452:28.46 mlnet Its still way bigger than anything else on the machine. Java objects = bloaty. http://c2.com/cgi/wiki?JavaObjectOverheadIsRidiculous I hope gcj's ahead of time compilation is capable of cutting down some of this bloat. (Notably, look how much smaller mlnet is. mldonkey supports bittorrent, though I haven't tried it yet. The control freak in me likes azureus, but my mere 512mb RAM is really hurting... hmmmm...) -------------- 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 tromey at redhat.com Thu Dec 15 23:38:56 2005 From: tromey at redhat.com (Tom Tromey) Date: 15 Dec 2005 16:38:56 -0700 Subject: Fedora meeting Mono Half-Way In-Reply-To: <1134689137.7509.41.camel@hamburger.booze> References: <43A155CF.4000500@3di.it> <43A1961F.8060706@cornell.edu> <20051215173531.GB9208@devserv.devel.redhat.com> <43A1B030.9030406@cornell.edu> <1134680116.7509.16.camel@hamburger.booze> <43A1E3AC.5020300@cornell.edu> <1134689137.7509.41.camel@hamburger.booze> Message-ID: >>>>> "Callum" == Callum Lerwick writes: Callum> Its still way bigger than anything else on the machine. Java Callum> objects = bloaty. Callum> http://c2.com/cgi/wiki?JavaObjectOverheadIsRidiculous The object "overhead" with gcj is the vtable pointer, plus of course whatever the GC needs for its bookkeeping (similar, I think, to whatever malloc would need). Synchronization is handled in a lookaside hash table; entries are only created for objects which are actually synchronized. The bits describing object layout to the GC are stuffed in the vtable, i.e., there is one GC descriptor per class, not per object. Callum> I hope gcj's ahead of time compilation is capable of cutting Callum> down some of this bloat. This question is more complicated than you might think. We can discuss it on the gcj list if you like. Tom From pquiring at hotmail.com Thu Dec 15 23:48:26 2005 From: pquiring at hotmail.com (Peter Jr. Quiring) Date: Thu, 15 Dec 2005 23:48:26 +0000 Subject: Shared vs Static (please read) Message-ID: I'm a C++ programmer that is porting from Windows to the Linux world. So far things are great. I've recently tried to use the -static option with gcc to generate binaries that are more portable, and so far it works. The only problem is that in FC5 the static libs are being removed (libjpeg-devel - see ticket # 145971). I understand that Shared libraries save space and this is good for software that is bundled with the OS, but for third party vendors, static would be a more ideal solution. I own my own company with one product available for Windows (currently it's my bread and butter). I don't have the resources available (just me) to release a Linux based solution for every major distro out there such as the Wine project does (fyi : I've contributed to that project - a few lines). The size of these libraries is not that much, my system only has 30MBs of static libs, compared to the 3GB disc image size. I tried to move a binary built on FC5 to a FC4 system and of course it didn't work (openssl version mismatch). So by removing static libs Fedora will be hurting the little guys (like me). I also know that some functions (like dlopen()) currently do not work in static mode, but some of my apps don't need this functionality. I've written my own DNS client, so the gethostaddr() etc functions I don't need. Does anyone know if it would be possible to use most libraries as static and maybe just use the shared version of dl, or glibc? I can see Linux (possibly Fedora) taking on Windows head-to-head some day, but without static libs Fedora would be crippling our options and force some of us to other options. If you would like to check out my "free" projects, goto http://digiforce.sourceforge.net and http://javaforce.sourceforge.net. Anyways, Thanks for listening. From jkeating at j2solutions.net Thu Dec 15 23:54:49 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Thu, 15 Dec 2005 15:54:49 -0800 Subject: Shared vs Static (please read) In-Reply-To: References: Message-ID: <1134690889.3005.96.camel@yoda.loki.me> On Thu, 2005-12-15 at 23:48 +0000, Peter Jr. Quiring wrote: > I'm a C++ programmer that is porting from Windows to the Linux world. So > far things are great. I've recently tried to use the -static option with > gcc to generate binaries that are more portable, and so far it works. The > only problem is that in FC5 the static libs are being removed (libjpeg-devel > - see ticket # 145971). I understand that Shared libraries save space and > this is good for software that is bundled with the OS, but for third party > vendors, static would be a more ideal solution. I own my own company with > one product available for Windows (currently it's my bread and butter). I > don't have the resources available (just me) to release a Linux based > solution for every major distro out there such as the Wine project does (fyi > : I've contributed to that project - a few lines). The size of these > libraries is not that much, my system only has 30MBs of static libs, > compared to the 3GB disc image size. > I tried to move a binary built on FC5 to a FC4 system and of course it > didn't work (openssl version mismatch). So by removing static libs Fedora > will be hurting the little guys (like me). I also know that some functions > (like dlopen()) currently do not work in static mode, but some of my apps > don't need this functionality. I've written my own DNS client, so the > gethostaddr() etc functions I don't need. Does anyone know if it would be > possible to use most libraries as static and maybe just use the shared > version of dl, or glibc? I don't know much about C++ compiling, but from a company standpoint, why can't you publish your software in source form, then do some builds for your targetted supported OSs, such as Fedora. If it is in source form, and uses dynamic linking, then folks that want your software in other distributions can rebuild it themselves? Better yet, pair up with a Fedora Extras maintainer so that your source gets built by the maintainer and pushed into Extras for all to use. Upstream doe source, distros compile it. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From loony at loonybin.org Fri Dec 16 00:07:40 2005 From: loony at loonybin.org (Peter Arremann) Date: Thu, 15 Dec 2005 19:07:40 -0500 Subject: Shared vs Static (please read) In-Reply-To: References: Message-ID: <200512151907.40723.loony@loonybin.org> On Thursday 15 December 2005 18:48, Peter Jr. Quiring wrote: > I can see Linux (possibly Fedora) taking on Windows head-to-head some day, > but without static libs Fedora would be crippling our options and force > some of us to other options. There has been much discussion about this over the years but eventually it always comes down to the fact that shared libraries are the way the Unix world has been going. There are two reasonable things you can do: 1) Get over it. Then you will have to compile and (should) package separately for different platforms (RHEL, Fedora, SuSE, Debian, ...) 2) Package the shared libraries. You still should package for the different platforms (which then leaves the questions on why you don't just compile for them specifically). Then, write a wrapper shell script and either uses LD_LIBRARY_PATH or LD_PRELOAD (depends on if you already loaded libs to be loaded or not) and then executes the real binary... Of course if you do 2, then you'll get lots of people that will complain the packaging... If you're serious, I can only recommend that you do it like everyone else does... Peter. From alan at redhat.com Fri Dec 16 00:25:08 2005 From: alan at redhat.com (Alan Cox) Date: Thu, 15 Dec 2005 19:25:08 -0500 Subject: Shared vs Static (please read) In-Reply-To: References: Message-ID: <20051216002508.GA23359@devserv.devel.redhat.com> On Thu, Dec 15, 2005 at 11:48:26PM +0000, Peter Jr. Quiring wrote: > I tried to move a binary built on FC5 to a FC4 system and of course it > didn't work (openssl version mismatch). So by removing static libs Fedora > will be hurting the little guys (like me). I also know that some openssl is a problem area certainly. > functions (like dlopen()) currently do not work in static mode, but some of > my apps don't need this functionality. I've written my own DNS client, so > the gethostaddr() etc functions I don't need. Does anyone know if it would > be possible to use most libraries as static and maybe just use the shared > version of dl, or glibc? To be honest Fedora is aimed at being cutting edge rather than being the proprietary high stability oriented platform. What you say is I think quite fair in terms of C++. For C the LSB has it mostly licked, for C++ the changing C++ ABI has been problematic. Usually btw the way to get good compatibility is to build on old. Old to new is generally very good (you might need to also ship copies of 'legacy' library versions for things like openssl) but glibc and the like work well and handle versioning. New to old is always trickier. Alan From nmiell at comcast.net Fri Dec 16 01:15:46 2005 From: nmiell at comcast.net (Nicholas Miell) Date: Thu, 15 Dec 2005 17:15:46 -0800 Subject: Shared vs Static (please read) In-Reply-To: <20051216002508.GA23359@devserv.devel.redhat.com> References: <20051216002508.GA23359@devserv.devel.redhat.com> Message-ID: <1134695746.2785.15.camel@entropy> On Thu, 2005-12-15 at 19:25 -0500, Alan Cox wrote: > On Thu, Dec 15, 2005 at 11:48:26PM +0000, Peter Jr. Quiring wrote: > > I tried to move a binary built on FC5 to a FC4 system and of course it > > didn't work (openssl version mismatch). So by removing static libs Fedora > > will be hurting the little guys (like me). I also know that some > > openssl is a problem area certainly. > > > functions (like dlopen()) currently do not work in static mode, but some of > > my apps don't need this functionality. I've written my own DNS client, so > > the gethostaddr() etc functions I don't need. Does anyone know if it would > > be possible to use most libraries as static and maybe just use the shared > > version of dl, or glibc? > > To be honest Fedora is aimed at being cutting edge rather than being the > proprietary high stability oriented platform. What you say is I think quite > fair in terms of C++. For C the LSB has it mostly licked, for C++ the changing > C++ ABI has been problematic. > Both the compiler ABI and the libstdc++ ABI. The former is understandable, but there's no excuse for the latter. Shared libraries using GNU C++ on ELF systems are a path to madness, and they'll stay that way until the libstdc++ people start practicing basic software maintenance skills, or glibc's ld.so gets support for DT_1_GROUP. -- Nicholas Miell From jkeating at redhat.com Fri Dec 16 01:19:35 2005 From: jkeating at redhat.com (Jesse Keating) Date: Thu, 15 Dec 2005 17:19:35 -0800 Subject: Java status Message-ID: <1134695975.3005.114.camel@yoda.loki.me> Only 3 packages remain in the java rebuild stack. jacorb xdoclet jonas All of these need some extra attention and they are getting it. Unfortunately not soon enough for tonight's rawhide roll. These are the last of the java stuff. -- Jesse Keating Release Engineer: Fedora From michael.favia at insitesinc.com Fri Dec 16 02:04:41 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Thu, 15 Dec 2005 20:04:41 -0600 Subject: bittorrent in core? what frontend? In-Reply-To: <1134684843.12010.173.camel@remedyz.boston.redhat.com> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <1134684843.12010.173.camel@remedyz.boston.redhat.com> Message-ID: <43A220B9.9000602@insitesinc.com> John (J5) Palmieri wrote: > On Thu, 2005-12-15 at 16:23 -0500, Jack Tanner wrote: >> John (J5) Palmieri wrote: >>> Not sure but I think the one in core should be the simplest. Click on >>> a .torrent file and a nice little progress bar pops up to tell you the >>> status and perhaps sits in the notification area. By all means though, >>> get Azureus to work and find someone to package it into extras. >> I don't mean to get into "my favorite client is X" debate, but if we're >> picking something for core, I'd argue for picking a client that people >> really love.[1] I've never used Azureus, but by that reasoning, since >> Azureus is regularly on sf.net's most downloaded/highest activity lists, >> it's a good choice. The "safe but boring" default client is a bad choice. >> >> [1] >> http://headrush.typepad.com/creating_passionate_users/2005/12/being_brave_is_.html > > And what happens when app XYZ becomes the flavor of the month? > Remember, not having it as the default doesn't mean it is not there. >>From the responses on this thread I would really encourage someone to > package Azureus up for extras because people do seem to love it. I can > imagine torrents becoming just like regular download. Oh how I would > hate it if every time I went to download a new tarball a huge management > window would pop up. All I would want is something to tell me it is > downloading and notify me when it is finished. > To that end i would also appreciate it if would configure UPnP for me and allow me to throttle the bandwidth or select files to exclude (especially in distro downloads). But then you end up with azureus minus the IRC client don't you? -mf From rc040203 at freenet.de Fri Dec 16 02:13:29 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Fri, 16 Dec 2005 03:13:29 +0100 Subject: funny user moment (and perhaps a bug) In-Reply-To: <1134663626.17385.139.camel@localhost.localdomain> References: <1134582427.30388.4.camel@willow.odshp.com> <12349.202.12.233.21.1134599074.squirrel@server.twofifty.bpa.nu> <1134632869.7509.10.camel@hamburger.booze> <1134652051.2968.6.camel@localhost.localdomain> <1134653825.30243.146.camel@mccallum.corsepiu.local> <1134663626.17385.139.camel@localhost.localdomain> Message-ID: <1134699209.30243.206.camel@mccallum.corsepiu.local> On Thu, 2005-12-15 at 08:20 -0800, Per Bjornsson wrote: > On Thu, 2005-12-15 at 14:37 +0100, Ralf Corsepius wrote: > > > Standard situations: > > * You login into your personal "desktop" in your office, and leave for > > another room, on the same network and want to login there ... > > * Several monitors on your desktop physically connected to different > > machines, but with a common and shared (networked) /home underneath. > > Actually that is very different from logging in several times on the > same machine. (Unless you use LTSP I guess, but that's not what you > said.) I don't know what LTSP is ;) Actually the situation I am talking about is quite simple: shared/networked /home on a file server, several desktop client machines. > logging in multiple times on separate machines sharing a > networked /home is supposed to be supported in Gnome; it has been > problematic occasionally but that's because of bugs. Well, the situation isn't as problematic as it used to be, but it still is far from being perfect, IMO. This starts with different machines having different screen resolutions/sizes and GNOME not being able to cope with this, over various tiny probs in sharing files and ends with running several instances of desktop applications in parallel on different machines, using the same /home underneath. Questions such as * How do/do applications detect other instances are sharing their resources (e.g. preferences, caches, desktop setup)? * How are user-customized machine-specific setups handled (e.g. having added hard-ware specific desktop applets)? as far as I can tell, to a large extend, these cases aren't handled "that well" at all in any GUI-toolkit/Desktop, but are left to be handled in applications and by the user ("don't run 2 instances of XXX"). Ralf From jspaleta at gmail.com Fri Dec 16 02:36:36 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 15 Dec 2005 21:36:36 -0500 Subject: funny user moment (and perhaps a bug) In-Reply-To: References: <1134582427.30388.4.camel@willow.odshp.com> <12349.202.12.233.21.1134599074.squirrel@server.twofifty.bpa.nu> <1134632869.7509.10.camel@hamburger.booze> <1134652051.2968.6.camel@localhost.localdomain> Message-ID: <604aa7910512151836y4d212ec1n7a34cb9efc69ba0c@mail.gmail.com> On 12/15/05, Jack Tanner wrote: > At the same time, I sit at my Windows box, log into the FC4 box via NX, > and run other user apps (Thunderbird, etc.) > > It seemed completely natural to me to use my desktop that way. This is only happening because you choose to use NX instead of the available vnc technology exposed via Gnome's vino. Helping to get NX support coded into vino so Desktop->preferences->remote desktop acts a NX session would prevent what you are seeing. Feel free to convince the NX people to work more closely with the Gnome developers to get native NX support working, or convince them to produce something similar to vino so you can avoid the unnecessary second login and reuse your existing local desktop which is already running. -jef From cmadams at hiwaay.net Fri Dec 16 03:26:39 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Thu, 15 Dec 2005 21:26:39 -0600 Subject: Shared vs Static (please read) In-Reply-To: References: Message-ID: <20051216032639.GD1496990@hiwaay.net> Once upon a time, Peter Jr. Quiring said: > I understand that Shared libraries > save space and this is good for software that is bundled with the OS, but > for third party vendors, static would be a more ideal solution. They don't just save space on the disk; they save RAM (as shared libraries can be shared between processes). > I tried to move a binary built on FC5 to a FC4 system and of course it > didn't work (openssl version mismatch). Another benefit of shared libraries is that a security or bugfix update to the library only requires a new library; all programs using the shared library get the fix. Any programs that used static linking will have to be rebuilt. OpenSSL has had several such security updates for example. Also, according to the terms of the LGPL (which for example glibc is licensed under), if link your program statically to an LGPL library, you need to include the object and/or source code of your program in any distribution (or an offer for the object and/or source) so that it could be relinked against the LGPLed library. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From fedora-devel-list at cygnusx-1.org Fri Dec 16 04:48:41 2005 From: fedora-devel-list at cygnusx-1.org (Nathan Grennan) Date: Thu, 15 Dec 2005 20:48:41 -0800 Subject: kernel-2.6.14-1.1653_FC4.netdev.6? In-Reply-To: <20051215162712.GC16712@redhat.com> References: <43A05044.7060803@cygnusx-1.org> <20051215005152.GF26108@rathann.pekin.waw.pl> <20051215010803.GE9801@redhat.com> <20051215162712.GC16712@redhat.com> Message-ID: <43A24729.2010304@cygnusx-1.org> John W. Linville wrote: > > kernel-2.6.14-1.1653_FC4.netdev.6 is available now: > > http://people.redhat.com/linville/kernels/fedora-netdev/ Thanks, seems to be working great so far. From mharris at mharris.ca Fri Dec 16 05:51:00 2005 From: mharris at mharris.ca (Mike A. Harris) Date: Fri, 16 Dec 2005 00:51:00 -0500 Subject: Default cursor theme for FC5. In-Reply-To: <1134655009.4464.24.camel@brilong-lnx> References: <439FD56B.8040608@web.de> <12238.194.94.224.254.1134550529.squirrel@arlette.freesurf.fr> <1134586894.7799.7.camel@orange.milkhost.com> <1134655009.4464.24.camel@brilong-lnx> Message-ID: <43A255C4.6040908@mharris.ca> Brian Long wrote: >>>There was a comment earlier about the FC4 cursors "busy" animated hour >>>glass being too busy. This may be true, but it is certainly less busy >>>than the blue spinning thing. >> >>Well at least you could *see* where the cursor is with the spinning >>hourglass. It never bothered me, apart from suffering from the problem 2) >>above as well to some extent. > > > I agree with Panu. Why Red Hat changed the theme between RHEL 4 U1 and > U2 is beyond me. The default cursor is "Bluecurve" in the X packaging, as it has been for a very long time now. If you got your cursors changed between U1 and U2, what were they before the change, and what are they now after the change? The only thing I can think of is if the actual graphic art for the Bluecurve cursor changed to someething else between U1 and U2. If you look at the index.theme file supplied with X however, you should see "Bluecurve" listed as the default theme in both U1 and U2, so if something has changed, it happened outside of X-land. However I guess RHEL update issues are a bit off topic for f-d-l. ;) Please let me know what you can determine nonetheless. -- Mike A. Harris, Open Source Advocate * http://mharris.ca Proud to be Canadian. From sundaram at redhat.com Fri Dec 16 06:12:57 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 16 Dec 2005 11:42:57 +0530 Subject: Default cursor theme for FC5. In-Reply-To: <43A255C4.6040908@mharris.ca> References: <439FD56B.8040608@web.de> <12238.194.94.224.254.1134550529.squirrel@arlette.freesurf.fr> <1134586894.7799.7.camel@orange.milkhost.com> <1134655009.4464.24.camel@brilong-lnx> <43A255C4.6040908@mharris.ca> Message-ID: <43A25AE9.6070007@redhat.com> Hi > > The only thing I can think of is if the actual graphic art for the > Bluecurve cursor changed to someething else between U1 and U2. Yes. The wait cursor did change between updates. Bluecurve just got refreshed same as in Fedora. regards Rahul From tmus at tmus.dk Fri Dec 16 06:57:10 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Fri, 16 Dec 2005 07:57:10 +0100 Subject: mirror synchronization flags? In-Reply-To: <43A1F69B.8030306@redhat.com> References: <1134569858.16389.21.camel@cutter> <1134621588.22019.45.camel@cutter> <1134687726.26513.19.camel@cutter> <1134687748.26513.21.camel@cutter> <43A1F69B.8030306@redhat.com> Message-ID: Rahul Sundaram wrote: > Details on Fedora mirror management at http://fedoraproject.org/wiki/Fedora > > regards > Rahul > Aha. Just the info I was looking for. :o) Thanks! /Thomas From arjan at fenrus.demon.nl Fri Dec 16 08:11:22 2005 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Fri, 16 Dec 2005 09:11:22 +0100 Subject: Shared vs Static (please read) In-Reply-To: References: Message-ID: <1134720683.2992.16.camel@laptopd505.fenrus.org> On Thu, 2005-12-15 at 23:48 +0000, Peter Jr. Quiring wrote: > I'm a C++ programmer that is porting from Windows to the Linux world. So > far things are great. I've recently tried to use the -static option with > gcc to generate binaries that are more portable, and so far it works. the problem is that due to a bunch of technicalities, -static binaries are LESS portable in linux, not more portable. http://people.redhat.com/drepper/no_static_linking.html However there is a middle ground; static link only the lib(s) that are a real portability problem, eg libstdc++, but not the rest. (at which point you need to be careful wrt the LGPL already but I don't know the exact details of the libstdc++ license, it may well have an exception for this). Linking openssl static sounds like a nightmare from a security update pov.... it's better to avoid it anyway in non-core-OS software due to the very unstable ABI. btw the way to only link libstdc++ static is this: -Wl,-static -lstdc++ -Wl,-dynamic From zaitcev at redhat.com Fri Dec 16 08:12:43 2005 From: zaitcev at redhat.com (Pete Zaitcev) Date: Fri, 16 Dec 2005 00:12:43 -0800 Subject: libusual interface [was Re: libusual and ub] In-Reply-To: <1134655233.2864.31.camel@bree.local.net> References: <20051029193544.096d400e.zaitcev@redhat.com> <20051215031822.GA12020@devserv.devel.redhat.com> <20051214211008.22c1ae47.zaitcev@redhat.com> <20051215053741.GA13787@devserv.devel.redhat.com> <20051215002129.4e9863e0.zaitcev@redhat.com> <1134655233.2864.31.camel@bree.local.net> Message-ID: <20051216001243.446d94e3.zaitcev@redhat.com> On Thu, 15 Dec 2005 09:00:33 -0500, Jeremy Katz wrote: > Hey, to be fair, my patch was just probing for the devices once ub > already got loaded. I ignored the question of "how does ub get loaded" > since I can guarantee that it happens in anaconda. BTW... Just to make sure that we're on the same page, if there's no working hotplug, you have to load both ub and usb-storage, because with libusual there is no way to know which is required for the particular device. In most cases, usb-storage is not needed, and it's a waste of about 30KB of RAM or so. But I see no (easy) way around it. > [...] So if we're going to build libusual > in statically, having the sysfs method to change the bias becomes > incredibly important (... as then I can just write to the file from the > loader and not worry about it) OK, that was a half an hour job. See attached, I'll ask Dave to include it and send it to upstream now. Note that there's no bind/unbind here, so it has to be set before the back end drivers are loaded. Out of curiousity, what part of the code makes these decisions: a) If to load USB storage drivers at all, whatever they are b) What of the available CD-ROMs has the ISO I would like to look. With ub, it is not obvious that the media is indeed a CD-ROM (or a DVD). Since ub issues no MODE SENSE command, everything is an array of blocks. So, suppose that everything works, how would you know that we're installing from /dev/uba or whatever? Do you try to read a header from everything that looks vaguely like a block device? That may cause interesting effects if you are attached to a SAN, so obviously you do not. Very curious. -- Pete From alexl at redhat.com Fri Dec 16 08:30:46 2005 From: alexl at redhat.com (Alexander Larsson) Date: Fri, 16 Dec 2005 09:30:46 +0100 Subject: bittorrent in core? what frontend? In-Reply-To: <20051215202126.GA4210@devserv.devel.redhat.com> References: <1134662961.28842.128.camel@greebo> <20051215202126.GA4210@devserv.devel.redhat.com> Message-ID: <1134721846.28842.166.camel@greebo> On Thu, 2005-12-15 at 15:21 -0500, Bill Nottingham wrote: > Alexander Larsson (alexl at redhat.com) said: > > I don't use bittorrent all that much. What do people think about these > > two frontends? Are there other interesting ones? > > I kept meaning to package gnome-bt for Extras, and kept forgetting. > So that would be my preference. :) One issue with gnome-bt is that it depends on the bittorrent package, and the bittorrent package already includes the default gui app, so unless you do some creative packaging you would get two bittorrent UIs with gnome-bt as the default. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a notorious white trash filmmaker on the hunt for the last specimen of a great and near-mythical creature. She's a psychotic gold-digging wrestler from the wrong side of the tracks. They fight crime! From zaitcev at redhat.com Fri Dec 16 08:32:26 2005 From: zaitcev at redhat.com (Pete Zaitcev) Date: Fri, 16 Dec 2005 00:32:26 -0800 Subject: libusual interface [was Re: libusual and ub] In-Reply-To: <1134655233.2864.31.camel@bree.local.net> References: <20051029193544.096d400e.zaitcev@redhat.com> <20051215031822.GA12020@devserv.devel.redhat.com> <20051214211008.22c1ae47.zaitcev@redhat.com> <20051215053741.GA13787@devserv.devel.redhat.com> <20051215002129.4e9863e0.zaitcev@redhat.com> <1134655233.2864.31.camel@bree.local.net> Message-ID: <20051216003226.4bb2b03d.zaitcev@redhat.com> On Thu, 15 Dec 2005 09:00:33 -0500, Jeremy Katz wrote: > [...] So if we're going to build libusual > in statically, having the sysfs method to change the bias becomes > incredibly important I forgot to attach the patch to the last mail. Not that you care, probably, but here it goes. -- Pete --- linux-2.6.14-1.1740_FC5/drivers/usb/storage/libusual.c 2005-12-06 23:47:49.000000000 -0800 +++ linux-2.6.14-lem/drivers/usb/storage/libusual.c 2005-12-15 23:47:48.000000000 -0800 @@ -24,10 +24,9 @@ static DEFINE_SPINLOCK(usu_lock); /* */ #define USB_US_DEFAULT_BIAS USB_US_TYPE_STOR +static atomic_t usu_bias = ATOMIC_INIT(USB_US_DEFAULT_BIAS); #define BIAS_NAME_SIZE (sizeof("usb-storage")) -static char bias[BIAS_NAME_SIZE]; -static int usb_usual_bias; static const char *bias_names[3] = { "none", "usb-storage", "ub" }; static DECLARE_MUTEX_LOCKED(usu_init_notify); @@ -35,7 +34,6 @@ static DECLARE_COMPLETION(usu_end_notify static atomic_t total_threads = ATOMIC_INIT(0); static int usu_probe_thread(void *arg); -static int parse_bias(const char *bias_s); /* * The table. @@ -107,7 +105,7 @@ int usb_usual_check_type(const struct us if (id_type == caller_type) return 0; /* Drivers grab devices biased to them */ - if (id_type == USB_US_TYPE_NONE && caller_type == usb_usual_bias) + if (id_type == USB_US_TYPE_NONE && caller_type == atomic_read(&usu_bias)) return 0; return -ENODEV; } @@ -124,7 +122,7 @@ static int usu_probe(struct usb_interfac type = USB_US_TYPE(id->driver_info); if (type == 0) - type = usb_usual_bias; + type = atomic_read(&usu_bias); spin_lock_irqsave(&usu_lock, flags); if ((stat[type].fls & (USU_MOD_FL_THREAD|USU_MOD_FL_PRESENT)) != 0) { @@ -206,9 +204,6 @@ static int __init usb_usual_init(void) { int rc; - bias[BIAS_NAME_SIZE-1] = 0; - usb_usual_bias = parse_bias(bias); - rc = usb_register(&usu_driver); up(&usu_init_notify); return rc; @@ -231,36 +226,42 @@ static void __exit usb_usual_exit(void) /* * Validate and accept the bias parameter. - * Maybe make an sysfs method later. XXX */ -static int parse_bias(const char *bias_s) +static int usu_set_bias(const char *bias_s, struct kernel_param *kp) { int i; + int len; int bias_n = 0; - if (bias_s[0] == 0 || bias_s[0] == ' ') { - bias_n = USB_US_DEFAULT_BIAS; - } else { - for (i = 1; i < 3; i++) { - if (strcmp(bias_s, bias_names[i]) == 0) { - bias_n = i; - break; - } - } - if (bias_n == 0) { - bias_n = USB_US_DEFAULT_BIAS; - printk(KERN_INFO - "libusual: unknown bias \"%s\", using \"%s\"\n", - bias_s, bias_names[bias_n]); + len = strlen(bias_s); + if (len == 0) + return -EDOM; + if (bias_s[len-1] == '\n') + --len; + + for (i = 1; i < 3; i++) { + if (strncmp(bias_s, bias_names[i], len) == 0) { + bias_n = i; + break; } } - return bias_n; + if (bias_n == 0) + return -EINVAL; + + atomic_set(&usu_bias, bias_n); + return 0; +} + +static int usu_get_bias(char *buffer, struct kernel_param *kp) +{ + return strlen(strcpy(buffer, bias_names[atomic_read(&usu_bias)])); } module_init(usb_usual_init); module_exit(usb_usual_exit); -module_param_string(bias, bias, BIAS_NAME_SIZE, S_IRUGO|S_IWUSR); +module_param_call(bias, usu_set_bias, usu_get_bias, NULL, S_IRUGO|S_IWUSR); +__MODULE_PARM_TYPE(bias, "string"); MODULE_PARM_DESC(bias, "Bias to usb-storage or ub"); MODULE_LICENSE("GPL"); From jakub at redhat.com Fri Dec 16 08:34:44 2005 From: jakub at redhat.com (Jakub Jelinek) Date: Fri, 16 Dec 2005 03:34:44 -0500 Subject: Shared vs Static (please read) In-Reply-To: <1134720683.2992.16.camel@laptopd505.fenrus.org> References: <1134720683.2992.16.camel@laptopd505.fenrus.org> Message-ID: <20051216083443.GP31785@devserv.devel.redhat.com> On Fri, Dec 16, 2005 at 09:11:22AM +0100, Arjan van de Ven wrote: > On Thu, 2005-12-15 at 23:48 +0000, Peter Jr. Quiring wrote: > > I'm a C++ programmer that is porting from Windows to the Linux world. So > > far things are great. I've recently tried to use the -static option with > > gcc to generate binaries that are more portable, and so far it works. > > the problem is that due to a bunch of technicalities, -static binaries > are LESS portable in linux, not more portable. > > http://people.redhat.com/drepper/no_static_linking.html > > However there is a middle ground; static link only the lib(s) that are a > real portability problem, eg libstdc++, but not the rest. (at which > point you need to be careful wrt the LGPL already but I don't know the > exact details of the libstdc++ license, it may well have an exception > for this). > > Linking openssl static sounds like a nightmare from a security update > pov.... it's better to avoid it anyway in non-core-OS software due to > the very unstable ABI. > > btw the way to only link libstdc++ static is this: > -Wl,-static -lstdc++ -Wl,-dynamic -Wl,-Bstatic -lstdc++ -Wl,-Bdynamic actually (and always make sure the command line ends in -Bdynamic state, as that's what will be used for the implicitly added libraries (-lc, -lgcc_s (sometimes), -lpthread (sometimes)). I should note that libstdc++ is not bad ABI-wise recently, GCC 3.4, 4.0 (and the upcoming 4.1) are all (backwards) binary compatible. So if you build against GCC 3.4 (e.g. FC3 or RHEL4), it will work on FC3/FC4/FC5/RHEL4/(likely RHEL5) libstdc++/C++ ABI wise as well as any other distro that ships with GCC 3.4/4.0/4.1. Of course other libraries like openssl might be a problem. Jakub From philipp_subx at redfish-solutions.com Fri Dec 16 08:43:56 2005 From: philipp_subx at redfish-solutions.com (Philip Prindeville) Date: Fri, 16 Dec 2005 01:43:56 -0700 Subject: Installing glib2-2.6.6-1 on FC3? In-Reply-To: <20051213114231.GC24704@neu.nirvana> References: <439E6402.6080802@redfish-solutions.com> <20051213114231.GC24704@neu.nirvana> Message-ID: <43A27E4C.3050204@redfish-solutions.com> Axel Thimm wrote: >On Mon, Dec 12, 2005 at 11:02:42PM -0700, Philip Prindeville wrote: > > >>I need to be able to build gdm-2.13.0.3 on FC3 to check some >>features and develop a couple of fixes that I naively volunteered >>to do, but... it seems that gdm-2.13 requires glib2-2.6.0 or better. >> >>Can I safely install glib2-2.6.6 on FC3 (using the RPMS on atrpms.net) >>or will that bugger things up badly? >> >> > >I would have to admit to be biased. It was promoted to the stable >section of ATrpms some ages ago after QAing it in bleeding and testing >repos, and several thousand of users are productively using it. > >And even if you don't take my word: The nice thing about packages is >that they can be cast back to their previous version. :) > > Well, I tried the following: # rpm -vv -e --nodeps glib2-2.4.8-1.fc3 glib2-devel-2.4.8-1.fc3.i386 # rpm -v -i http://dl.atrpms.net/all/glib2-2.6.6-1_12.rhfc3.at.i386.rpm http://dl.atrpms.net/all/libglib-2.0_0-2.6.6-1_12.rhfc3.at.i386.rpm http://dl.atrpms.net/all/libgthread-2.0_0-2.6.6-1_12.rhfc3.at.i386.rpm http://dl.atrpms.net/all/libgobject-2.0_0-2.6.6-1_12.rhfc3.at.i386.rpm http://dl.atrpms.net/all/libgmodule-2.0_0-2.6.6-1_12.rhfc3.at.i386.rpm http://dl.atrpms.net/all/glib2-devel-2.6.6-1_12.rhfc3.at.i386.rpm and it installed, but... Trying to do a build of GDM blew up, and I suspect other things will eventually over time as well (which reminds me: is there a good way to exorcise programs that dynamically link to glib2 and make sure they all perform in a reasonably sane manner?): # ./autogen.sh /usr/bin/gnome-autogen.sh checking for autoconf >= 2.53... testing autoconf2.50... not found. testing autoconf... found 2.59 checking for automake >= 1.5... testing automake-1.9... found 1.9.2 checking for libtool >= 1.4.3... testing libtoolize... found 1.5.6 checking for glib-gettext >= 2.2.0... testing glib-gettextize... not found. ***Error***: You must have glib-gettext >= 2.2.0 installed to build GDM. Download the appropriate package for from your distribution or get the source tarball at ftp://ftp.gtk.org/pub/gtk/v2.2/glib-2.2.0.tar.gz checking for intltool >= 0.25... testing intltoolize... found 0.31.2 checking for pkg-config >= 0.14.0... testing pkg-config... found 0.15.0 checking for gnome-doc-utils >= 0.4.2... testing gnome-doc-prepare... found 0.5.1 Checking for required M4 macros... glib-gettext.m4 not found Checking for forbidden M4 macros... ***Error***: some autoconf macros required to build GDM were not found in your aclocal path, or some forbidden macros were found. Perhaps you need to adjust your ACLOCAL_FLAGS? # I'll grab glib-2.2.3.tar.bz2, but I don't know about some of these other issues. Anyone have a .spec file to build GDM 2.13.0.3 on FC3 or any suggestions on how to go about that? Thanks, -Philip From buildsys at redhat.com Fri Dec 16 09:12:31 2005 From: buildsys at redhat.com (Build System) Date: Fri, 16 Dec 2005 04:12:31 -0500 Subject: rawhide report: 20051216 changes Message-ID: <200512160912.jBG9CV5E009998@porkchop.devel.redhat.com> New package aspell-sl Slovenian dictionaries for Aspell. New package iscsi-initiator-utils iSCSI daemon and utility programs New package m17n-db Multilingualization datafiles for m17n-lib New package m17n-lib Multilingual text library New package scim-m17n SCIM IMEngine for m17n-lib Updated Packages: GConf-1.0.9-18 -------------- * Thu Dec 15 2005 Ray Strode 1.0.9-18 - take ownership of directories that belong to the package (bug 151360) MySQL-python-1.2.0-3.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt anaconda-10.90.21-1 ------------------- * Thu Dec 15 2005 Jeremy Katz - 10.90.21-1 - fix pkgorder for new group code - fix ub vs usb-storage - remove some redundant code (clumens) * Thu Dec 15 2005 Jeremy Katz - 10.90.20-1 - Fixes for new timezone stuff (pnasrat) - Fix transaction sorting (pnasrat) - Enable dmraid by default avalon-framework-0:4.1.4-2jpp_6fc --------------------------------- * Thu Dec 15 2005 Gary Benson 0:4.1.4-2jpp_6fc - Rebuild for new gcj. bash-3.0-41 ----------- * Thu Dec 15 2005 Tim Waugh 3.0-41 - Missed another loop for improved sighandler patch (bug #169231). carol-0:1.8.9.3-1jpp_7fc ------------------------ * Fri Dec 09 2005 Jesse Keating 0:1.8.9.3-1jpp_7fc - rebuilt epiphany-1.9.3.1-1 ------------------ * Thu Dec 15 2005 Matthias Clasen 1.9.3.1-1 - Update to 1.9.3.1 evolution-2.5.2-2 ----------------- * Thu Dec 15 2005 Christopher Aillon 2.5.2-2 - Require nspr and nss instead of mozilla-nspr and mozilla-nss - Update no-gnome-common patch to work with standalone nss package finger-0.17-32 -------------- * Thu Dec 15 2005 Radek Vokal 0.17-32 - another UTF-8 fix gcc-4.1.0-0.8 ------------- * Mon Dec 12 2005 Jakub Jelinek 4.1.0-0.8 - update from gcc-4_1-branch (-r108414:108539) - PRs classpath/25389, fortran/23815, fortran/25078, target/25254 - fix Java ICE on initialized static final var used in case (Andrew Haley, #175569) - fix crash in _Unwind_IteratePhdrCallback (Andrew Haley) - don't Require alsa-lib-devel, just BuildRequire it (#175627) - use .gnu.linkonce.d.rel.ro.* sections for objects that are constant after relocation processing gimp-print-4.2.7-14 ------------------- * Thu Dec 15 2005 Tim Waugh 4.2.7-14 - Several fixes for gimp-print-cups scriptlets (bug #175710, bug #175722). gnome-panel-2.13.3-1 -------------------- * Thu Dec 15 2005 Matthias Clasen 2.13.3-1 - Update to 2.13.3 - Use sed rather than patch for po files gnome-screensaver-0.0.22-1 -------------------------- * Thu Dec 15 2005 Matthias Clasen - 0.0.22-1 - Update to 0.0.22 gnome-terminal-2.13.0-1 ----------------------- * Thu Dec 15 2005 Matthias Clasen 2.13.0-1 - Update to 2.13.0 gnome-utils-1:2.13.3-1 ---------------------- * Thu Dec 15 2005 Matthias Clasen 2.13.3 - Update to gnome-utils 2.13.3 - Update to zenity 2.13.3 - Update to gucharmap 1.5.0 - Update to gcalctool 5.7.15 - Drop upstreamed patch gnome-vfs2-2.13.3-1 ------------------- * Thu Dec 15 2005 Matthias Clasen 2.13.3-1 - Update to 2.13.3 - Drop upstreamed patches gnome-volume-manager-1.5.5-1 ---------------------------- * Thu Dec 15 2005 Matthias Clasen - 1.5.5-1 - Update to 1.5.5 gnomemeeting-1.2.3-1 -------------------- * Tue Dec 13 2005 Daniel Veillard 1.2.3-1 - upstream release of 1.2.3 - Fixes for gcc 4.1 * Fri Dec 09 2005 Jesse Keating - rebuilt gnopernicus-1.0.0-1 ------------------- * Thu Dec 15 2005 Matthias Clasen 1.0.0-1 - Update to 1.0.0 - Work around wrong-evaluation-time issues in configure gtksourceview-1.5.2-1 --------------------- * Wed Dec 14 2005 Matthias Clsaen - Update to 1.5.2 - Remove upstreamed patch initscripts-8.19-1 ------------------ * Thu Dec 15 2005 Bill Nottingham - Require syslog, for alternate implementations thereof (#172885) - Fix fsck invocation for weeding out netdev devices (#175803) * Fri Dec 02 2005 Bill Nottingham 8.18-1 - use new dhclient file paths, add appropriate conflict (#169164) * Wed Oct 05 2005 Bill Nottingham 8.17-1 - make sure corefile limiting works for user processes as well (#166511, ) - ifup-routes: handle no EOF in the route file (#156972) - rc.sysinit: tweak mesage (#156972) - ifdown-eth: clean up error message (#135167) - rc.sysinit: call kpartx on multipath devices (#160227) - ifup-eth: move wireless options before bridge options (#122801) - ifup-wireless: silence error (#90601) - init.d/functions: change translated string (#54682) jakarta-commons-beanutils-0:1.7.0-2jpp_3fc ------------------------------------------ * Fri Dec 09 2005 Jesse Keating - 0:1.7.0-2jpp_3fc - rebuilt * Tue Jul 19 2005 Gary Benson - 0:1.7.0-2jpp_2fc - Build on ia64, ppc64, s390 and s390x. - Switch to aot-compile-rpm. * Wed May 25 2005 Gary Benson - 0:1.7.0-2jpp_1fc - Upgrade to 1.7.0-2jpp. - Rearrange how BC-compiled stuff is built and installed. jakarta-commons-cli-0:1.0-6jpp_2fc ---------------------------------- * Fri Dec 09 2005 Jesse Keating - 0:1.0-6jpp_2fc - rebuilt * Thu Jun 16 2005 Gary Benson - 0:1.0-6jpp_1fc - Build into Fedora. * Mon Dec 20 2004 Fernando Nasser - 0:1.0-6jpp_1rh - First Red Hat release jakarta-commons-discovery-1:0.3-1jpp_2fc ---------------------------------------- * Fri Dec 09 2005 Jesse Keating -1:1:0.3-1jpp_2fc - rebuilt * Thu Jun 16 2005 Gary Benson - 1:1:0.3-1jpp_1fc - Build into Fedora. * Sat Jun 04 2005 Fernando Nasser - 1:1:0.3-1jpp_1rh - Merge for update jakarta-commons-el-0:1.0-4jpp_3fc --------------------------------- * Fri Dec 09 2005 Jesse Keating - 0:1.0-4jpp_3fc - rebuilt * Tue Jul 19 2005 Gary Benson - 0:1.0-4jpp_2fc - Build on ia64, ppc64, s390 and s390x. - Switch to aot-compile-rpm. * Tue Jun 14 2005 Gary Benson - 0:1.0-4jpp_1fc - Upgrade to 1.0-4jpp. jakarta-commons-fileupload-1:1.0-3jpp_2fc.1 ------------------------------------------- * Fri Dec 09 2005 Jesse Keating - 1:1.0-3jpp_2fc - rebuilt * Thu Jan 20 2005 Gary Benson - 1:1.0-3jpp_1fc - Build into Fedora. * Fri Oct 22 2004 Fernando Nasser 1:1.0-3jpp_1rh - Merge with upstream version jakarta-commons-httpclient-1:3.0-0.rc2.0jpp_2fc ----------------------------------------------- * Fri Dec 09 2005 Jesse Keating - 1:3.0-0.rc2.0jpp_2fc - rebuilt * Wed Jun 15 2005 Gary Benson - 1:3.0-0.rc2.0jpp_1fc - Build into Fedora. * Tue Jun 07 2005 Gary Benson - Avoid an API hole in libgcj's Swing implementation. - Skip tests (suite is full of Sun-specific classes). jakarta-commons-logging-0:1.0.4-2jpp_7fc ---------------------------------------- * Fri Dec 09 2005 Jesse Keating - 0:1.0.4-2jpp_7fc - rebuilt * Fri Jul 15 2005 Gary Benson - 0:1.0.4-2jpp_6fc - Build on ia64, ppc64, s390 and s390x. - Switch to aot-compile-rpm. * Wed May 25 2005 Gary Benson - 0:1.0.4-2jpp_5fc - Rearrange how BC-compiled stuff is built and installed. jakarta-commons-modeler-0:1.1-4jpp_3fc -------------------------------------- * Fri Dec 09 2005 Jesse Keating - 0:1.1-4jpp_3fc - rebuilt * Wed Jul 20 2005 Gary Benson - 0:1.1-4jpp_2fc - Build on ia64, ppc64, s390 and s390x. - Switch to aot-compile-rpm. * Thu May 26 2005 Gary Benson - 0:1.1-4jpp_1fc - Upgrade to 1.1-4jpp. - Rearrange how BC-compiled stuff is built and installed. jakarta-commons-validator-0:1.1.3-1jpp_3fc ------------------------------------------ * Fri Dec 09 2005 Jesse Keating - 0:1.1.3-1jpp_3fc - rebuilt * Tue Jun 21 2005 Gary Benson - 0:1.1.3-1jpp_2fc - Remove jarfile from the tarball. * Thu Jan 20 2005 Gary Benson - 0:1.1.3-1jpp_1fc - Build into Fedora. jgroups-0:2.2.6-1jpp_2fc ------------------------ * Fri Dec 09 2005 Jesse Keating 0:2.2.6-1jpp_2fc - rebuilt * Thu Jun 16 2005 Gary Benson 0:2.2.6-1jpp_1fc - Build into Fedora. * Thu Jun 09 2005 Gary Benson - Remove jarfiles from the tarball. jonathan-core-0:4.1-1jpp_5fc ---------------------------- * Fri Dec 09 2005 Jesse Keating 0:4.1-1jpp_5fc - rebuilt * Mon Aug 01 2005 Gary Benson 0:4.1-1jpp_4fc - Build on ia64, ppc64, s390 and s390x. - Switch to aot-compile-rpm. * Tue Jun 28 2005 Gary Benson 0:4.1-1jpp_3fc - BC-compile. jonathan-jeremie-0:4.2-1jpp_5fc ------------------------------- * Fri Dec 09 2005 Jesse Keating 0:4.2-1jpp_5fc - rebuilt * Mon Aug 01 2005 Gary Benson 0:4.2-1jpp_4fc - Remove explicit references to jacorb and jonathan-rmi. - Switch to aot-compile-rpm. - Build on ia64, ppc64, s390 and s390x. * Tue Jun 28 2005 Gary Benson 0:4.2-1jpp_3fc - BC-compile. jotm-0:2.0.5-1jpp_4fc --------------------- * Fri Dec 09 2005 Jesse Keating 0:2.0.5-1jpp_4fc - rebuilt kasumi-1.0-1.fc5 ---------------- * Thu Dec 15 2005 Akira TAGOH - 1.0-1 - New upstream release. - kasumi-1.0-gcc41.patch: build with -ffriend-injection to temporarily get it built with gcc-4.1. * Fri Dec 09 2005 Jesse Keating - rebuilt kernel-2.6.14-1.1767_FC5 ------------------------ * Thu Dec 15 2005 Dave Jones - 2.6.15-rc5-git5 * Wed Dec 14 2005 Dave Jones - 2.6.15-rc5-git4 - Try 'optimise for size' again. - Silence noisy CD drives that spew msgs when probed whilst empty. * Tue Dec 13 2005 Dave Jones - 2.6.15-rc5-git3 - Use MMIO instead of PIO for 8139too libICE-0.99.2-1 --------------- * Tue Dec 13 2005 Mike A. Harris 0.99.2-1 - Updated libICE to version 0.99.2 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Fri Dec 09 2005 Jesse Keating - rebuilt libXScrnSaver-0.99.3-1 ---------------------- * Tue Dec 13 2005 Mike A. Harris 0.99.3-1 - Updated libXScrnSaver to version 0.99.3 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Fri Dec 09 2005 Jesse Keating - rebuilt libXau-0.99.2-1 --------------- * Tue Dec 13 2005 Mike A. Harris 0.99.2-1 - Updated libXau to version 0.99.2 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Fri Dec 09 2005 Jesse Keating - rebuilt libXaw-0.99.3-1 --------------- * Tue Dec 13 2005 Mike A. Harris 0.99.3-1 - Updated libXaw to version 0.99.3 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Fri Dec 09 2005 Jesse Keating - rebuilt libXcomposite-0.2.2.1-1 ----------------------- * Tue Dec 13 2005 Mike A. Harris 0.2.2.1-1 - Updated libXcomposite to version 0.2.2.1 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Fri Dec 09 2005 Jesse Keating - rebuilt libXdamage-1.0.2.1-1 -------------------- * Tue Dec 13 2005 Mike A. Harris 1.0.2.1-1 - Updated libXdamage to version 1.0.2.1 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Fri Dec 09 2005 Jesse Keating - rebuilt libXdmcp-0.99.2-1 ----------------- * Tue Dec 13 2005 Mike A. Harris 0.99.2-1 - Updated libXdmcp to version 0.99.2 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Fri Dec 09 2005 Jesse Keating - rebuilt libXevie-0.99.3-1 ----------------- * Tue Dec 13 2005 Mike A. Harris 0.99.3-1 - Updated libXevie to version 0.99.3 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Fri Dec 09 2005 Jesse Keating - rebuilt libXext-0.99.3-1 ---------------- * Tue Dec 13 2005 Mike A. Harris 0.99.3-1 - Updated libXext to version 0.99.3 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Fri Dec 09 2005 Jesse Keating - rebuilt libXfixes-3.0.1.1-1 ------------------- * Tue Dec 13 2005 Mike A. Harris 3.0.1.1-1 - Updated libXfixes to version 3.0.1.1 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Fri Dec 09 2005 Jesse Keating - rebuilt libXfont-0.99.3-1 ----------------- * Tue Dec 13 2005 Mike A. Harris 0.99.3-1 - Updated libXfont to version 0.99.3 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. - Removed libXfont-0.99.2-fontdir-attrib-fix-bug-172997.patch, which is now integrated upstream. * Fri Dec 09 2005 Jesse Keating - rebuilt * Mon Nov 14 2005 Mike A. Harris 0.99.2-3 - Added libXfont-0.99.2-fontdir-attrib-fix-bug-172997.patch to remove conditionalization of FONTDIRATTRIB from sources instead of tweaking CFLAGS for bug (#172997, fdo#5047). libXfontcache-0.99.2-1 ---------------------- * Tue Dec 13 2005 Mike A. Harris 0.99.2-1 - Updated libXfontcache to version 0.99.2 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. - Added new manpages to file manifest. * Tue Nov 15 2005 Mike A. Harris 0.99.1-3 - Added "BuildRequires: libXau-devel", as twm fails without it, but does not check for it with ./configure. Bug (fdo#5065) libXi-0.99.2-1 -------------- * Tue Dec 13 2005 Mike A. Harris 0.99.2-1 - Updated libXi to version 0.99.2 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Tue Nov 15 2005 Mike A. Harris 0.99.1-3 - Added "BuildRequires: libXau-devel", as build fails without it, but does not check for it with ./configure. Bug (fdo#5065) libXinerama-0.99.2-1 -------------------- * Tue Dec 13 2005 Mike A. Harris 0.99.2-1 - Updated libXinerama to version 0.99.2 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Tue Nov 15 2005 Mike A. Harris 0.99.1-3 - Added "BuildRequires: libXau-devel", as twm fails without it, but does not check for it with ./configure. Bug (fdo#5065) libXmu-0.99.2-1 --------------- * Tue Dec 13 2005 Mike A. Harris 0.99.2-1 - Updated libXmu to version 0.99.2 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. - Added "BuildRequires: pkgconfig, libXau-devel, xorg-x11-util-macros" to fix build dependencies. * Fri Dec 09 2005 Jesse Keating - rebuilt libXp-0.99.2-1 -------------- * Tue Dec 13 2005 Mike A. Harris 0.99.2-1 - Updated libXp to version 0.99.2 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Fri Dec 09 2005 Jesse Keating - rebuilt libXpm-3.5.4.1-1 ---------------- * Tue Dec 13 2005 Mike A. Harris 3.5.4.1-1 - Updated libXpm to version 3.5.4.1 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. - Added "Requires: libX11-devel" to devel subpackage as xpm.h includes various X headers. (#174163) - Added missing build dep libXau-devel * Fri Dec 09 2005 Jesse Keating - rebuilt libXrandr-1.1.0.1-1 ------------------- * Tue Dec 13 2005 Mike A. Harris 1.1.0.1-1 - Updated libXrandr to version 1.1.0.1 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Fri Dec 09 2005 Jesse Keating - rebuilt libXrender-0.9.0.1-1 -------------------- * Tue Dec 13 2005 Mike A. Harris 0.9.0.1-1 - Updated libXrender to version 0.9.0.1 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Fri Dec 09 2005 Jesse Keating - rebuilt libXres-0.99.3-1 ---------------- * Tue Dec 13 2005 Mike A. Harris 0.99.3-1 - Updated libXres to version 0.99.3 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Fri Dec 09 2005 Jesse Keating - rebuilt libXt-0.99.3-1 -------------- * Tue Dec 13 2005 Mike A. Harris 0.99.3-1 - Updated libXt to version 0.99.3 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Fri Dec 09 2005 Jesse Keating - rebuilt libXtst-0.99.3-1 ---------------- * Tue Dec 13 2005 Mike A. Harris 0.99.3-1 - Updated libXtst to version 0.99.3 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Fri Dec 09 2005 Jesse Keating - rebuilt libXv-0.99.2-1 -------------- * Tue Dec 13 2005 Mike A. Harris 0.99.2-1 - Updated libXv to version 0.99.2 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Fri Dec 09 2005 Jesse Keating - rebuilt libXvMC-0.99.2-1 ---------------- * Tue Dec 13 2005 Mike A. Harris 0.99.2-1 - Updated libXvMC to version 0.99.2 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Fri Dec 09 2005 Jesse Keating - rebuilt libXxf86dga-0.99.3-1 -------------------- * Tue Dec 13 2005 Mike A. Harris 0.99.3-1 - Updated libXxf86dga to version 0.99.3 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Fri Dec 09 2005 Jesse Keating - rebuilt libXxf86misc-0.99.2-1 --------------------- * Tue Dec 13 2005 Mike A. Harris 0.99.2-1 - Updated libXxf86misc to version 0.99.2 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Fri Dec 09 2005 Jesse Keating - rebuilt libXxf86vm-0.99.2-1 ------------------- * Tue Dec 13 2005 Mike A. Harris 0.99.2-1 - Updated libXxf86vm to version 0.99.2 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Fri Dec 09 2005 Jesse Keating - rebuilt libdmx-0.99.2-1 --------------- * Tue Dec 13 2005 Mike A. Harris 0.99.2-1 - Updated libdmx to version 0.99.2 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Tue Nov 15 2005 Mike A. Harris 0.99.1-3 - Added "BuildRequires: libXau-devel, pkgconfig" missing deps. libdrm-2.0-1 ------------ * Wed Nov 30 2005 Mike A. Harris 2.0-1 - Updated libdrm to version 2.0 from dri.sf.net. This is an ABI incompatible release, meaning everything linked to it needs to be recompiled. libfontenc-0.99.3-1 ------------------- * Tue Dec 13 2005 Mike A. Harris 0.99.3-1 - Updated libfontenc to version 0.99.3 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. libgtop2-2.13.1-1 ----------------- * Thu Dec 15 2005 Matthias Clasen - Update to 2.13.1 * Wed Dec 14 2005 Matthias Clasen - Update to 2.13.0 * Fri Dec 09 2005 Jesse Keating - rebuilt liblbxutil-0.99.3-1 ------------------- * Tue Dec 13 2005 Mike A. Harris 0.99.3-1 - Updated liblbxutil to version 0.99.3 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Fri Dec 09 2005 Jesse Keating - rebuilt liboldX-0.99.2-1 ---------------- * Tue Dec 13 2005 Mike A. Harris 0.99.2-1 - Updated liboldX to version 0.99.2 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Fri Dec 09 2005 Jesse Keating - rebuilt libxkbfile-0.99.2-1 ------------------- * Tue Dec 13 2005 Mike A. Harris 0.99.2-1 - Updated libxkbfile to version 0.99.2 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Fri Dec 09 2005 Jesse Keating - rebuilt libxkbui-0.99.2-1 ----------------- * Tue Dec 13 2005 Mike A. Harris 0.99.2-1 - Updated libxkbui to version 0.99.2 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Fri Dec 09 2005 Jesse Keating - rebuilt lucene-0:1.4.3-1jpp_9fc ----------------------- * Wed Dec 14 2005 Gary Benson - 0:1.4.3-1jpp_9fc - Rebuilt for new gcj. * Tue Dec 13 2005 Jesse Keating - rebuilt for new gcj * Fri Nov 11 2005 Vadim Nasardinov - 0:1.4.3-1jpp_8fc - BZ 170343 -- add the lucene-devel subpackage medor-0:1.4.4-1jpp_2fc ---------------------- medor-expression-0:1.4.2-1jpp_2fc --------------------------------- mockobjects-0:0.09-12jpp_3fc ---------------------------- * Fri Dec 09 2005 Jesse Keating 0:09-11jpp_3fc - rebuilt monolog-0:1.8.6-1jpp_10fc ------------------------- * Fri Dec 09 2005 Jesse Keating 0:1.8.6-1jpp_10fc - rebuilt - patch to accept jdk 1.5 mozilla-37:1.7.12-3 ------------------- * Thu Dec 15 2005 Christopher Aillon 37:1.7.12-3 - Use system NSS * Fri Dec 09 2005 Jesse Keating - rebuilt mysql-5.0.16-4 -------------- * Thu Dec 15 2005 Tom Lane 5.0.16-4 - fix my_config.h for ppc platforms * Thu Dec 15 2005 Tom Lane 5.0.16-3 - my_config.h needs to guard against 64-bit platforms that also define the 32-bit symbol * Wed Dec 14 2005 Tom Lane 5.0.16-2 - oops, looks like we want uname -i not uname -m mysql-connector-odbc-3.51.12-1.1 -------------------------------- mysqlclient10-3.23.58-9 ----------------------- * Thu Dec 15 2005 Tom Lane 3.23.58-9 - fix my_config.h for 64-bit and ppc platforms mysqlclient14-4.1.14-4 ---------------------- * Thu Dec 15 2005 Tom Lane 4.1.14-4 - fix my_config.h for 64-bit and ppc platforms nautilus-cd-burner-2.13.3-1 --------------------------- * Thu Dec 15 2005 Matthias Clasen 2.13.3-1 - Update to 2.13.3 * Fri Dec 09 2005 Jesse Keating - rebuilt nspr-4.6.1-1 ------------ * Thu Dec 15 2005 Christopher Aillon 4.6.1-1 - Update to 4.6.1 nss-3.11-1 ---------- * Thu Dec 15 2005 Christopher Aillon 3.11-1 - Update to 3.11 * Thu Dec 15 2005 Christopher Aillon 3.11-0.cvs.2 - Add patch to allow building on ppc* - Update the pkgconfig file to Require nspr * Thu Dec 15 2005 Christopher Aillon 3.11-0.cvs - Initial import into Fedora Core, based on a CVS snapshot of the NSS_3_11_RTM tag - Fix up the pkcs11-devel subpackage to contain the proper headers - Build with RPM_OPT_FLAGS - No need to have rpath of /usr/lib in the pc file openoffice.org-1:2.0.1-145.3.2 ------------------------------ * Tue Dec 13 2005 Caolan McNamara - 1:2.0.1-145.3 - system agg openssl-0.9.8a-5 ---------------- * Thu Dec 15 2005 Tomas Mraz 0.9.8a-5 - don't include SSL_OP_NETSCAPE_REUSE_CIPHER_CHANGE_BUG in SSL_OP_ALL (#175779) pam-0.99.2.1-1 -------------- * Thu Dec 15 2005 Tomas Mraz 0.99.2.1-1 - support netgroup matching in pam_succeed_if - upgrade to new release - drop pam_pwdb as it was obsolete long ago - we don't build static libraries anymore postgresql-8.1.1-3 ------------------ * Thu Dec 15 2005 Tom Lane 8.1.1-3 - fix pg_config.h for 64-bit and ppc platforms - update Makefile.regress (needs to --load-language=plpgsql) procps-3.2.6-3 -------------- * Tue Dec 13 2005 Dan Walsh 3.2.6-3 - Translate context python-pyblock-0.8-1 -------------------- * Thu Dec 15 2005 Peter Jones - 0.8-1 - prevent getRaidSets() from returning devices with missing members - add "make flat_install" to make installing in RHupdates easier ;) rhdb-utils-8.1.1-1.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt scim-1.4.2-8 ------------ * Fri Dec 16 2005 Jens Petersen - 1.4.2-8 - rebuild with gcc-4.1 * Mon Nov 14 2005 Jens Petersen - 1.4.2-7 - make "reload config" reload IMEs with scim-reload-engines-165655.patch (Qian Shen, #165655) - add iiimf obsoletes for upgrading (#173071) * Tue Nov 01 2005 Jens Petersen - 1.4.2-6 - avoid errors in postun script when uninstalling scim-anthy-0.8.0-1.fc5.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt scim-chewing-0.2.1-4 -------------------- * Fri Dec 16 2005 Jens Petersen - 0.2.1-4 - rebuild with gcc-4.1 scim-hangul-0.2.1-2.fc5.1 ------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt scim-pinyin-0.5.91-3.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt scim-tables-0.5.5-1.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt selinux-policy-2.1.6-4 ---------------------- * Wed Dec 14 2005 Dan Walsh 2.1.5-4 - Fixes to allow automount to use portmap - Fixes to start kernel in s0-s15:c0.c255 struts-0:1.2.4-2jpp_4fc ----------------------- * Fri Dec 09 2005 Jesse Keating - 0:1.2.4-2jpp_4fc - rebuilt sysklogd-1.4.1-34 ----------------- * Thu Dec 15 2005 Jason Vas Dias 1.4.1rh-34 - Add 'Provides: syslog' for bug 172885 * Fri Dec 09 2005 Jesse Keating - rebuilt system-config-date-1.7.99.11-1 ------------------------------ * Thu Dec 15 2005 Jeremy Katz - 1.7.99.11-1 - fix timezone map to not be painfully slow tog-pegasus-2:2.5-5 ------------------- * Thu Dec 15 2005 Jason Vas Dias - 2:2.5-5 - fix bug 175434 : deal with pegasus uid/gid already existing on first install * Fri Dec 09 2005 Jesse Keating - 2:2.5-4.1 - rebuilt * Wed Nov 16 2005 Jason Vas Dias - 2:2.5-4 - fix bug 173401: SSL support broken by openssl-0.9.7g -> 0.9.8a upgrade tomcat5-0:5.0.30-8jpp_6fc ------------------------- * Fri Dec 09 2005 Jesse Keating 0:5.0.30-8jpp_6fc - rebuilt - patched util's build.xml to not use target=1.1 totem-1.2.1-1 ------------- * Thu Dec 15 2005 Matthias Clasen 1.2.1-1 - Update to 1.2.1 udev-077-2 ---------- * Thu Dec 15 2005 Harald Hoyer - 077-2 - switched back to udevstart and use active /dev/.udev/queue waiting in start_udev - removed support for old kernels - refined some udev.rules unixODBC-2.2.11-6.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt velocity-0:1.4-3jpp_2fc ----------------------- * Fri Dec 09 2005 Jesse Keating - 0:1.4-3jpp_2fc - rebuilt * Tue Nov 08 2005 Vadim Nasardinov - 0:1.4-3jpp_1fc - Converted from ISO-8859-1 to UTF-8 vixie-cron-4:4.1-42.FC5 ----------------------- * Thu Dec 15 2005 Jason Vas Dias - fix bug 172885: Replace Requires:sysklogd with Requires:syslog * Fri Dec 09 2005 Jesse Keating - rebuilt vte-0.11.16-1.fc5.1 ------------------- * Thu Dec 15 2005 Matthias Clasen 0.11.16-1 - Update to 0.11.16 xmlsec1-1.2.9-4 --------------- * Thu Dec 15 2005 Christopher Aillon 1.2.9-4 - NSS has been split out of the mozilla package, so require that now and update separate_nspr.patch to account for the new NSS as well * Fri Dec 09 2005 Jesse Keating - rebuilt Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel = 0:2.6.14-1.1696_FC5 cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5smp cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 eclipse-bugzilla - 1:0.1.1_fc-5.i386 requires libgcj.so.6 eclipse-cdt - 1:3.0.1-1jpp_1fc.i386 requires libgcj.so.6 eclipse-changelog - 1:2.0.1_fc-22.i386 requires libgcj.so.6 eclipse-ecj - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-jdt - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-pde - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-platform - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 eclipse-pydev - 1:0.9.3_fc-12.i386 requires libgcj.so.6 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel = 0:2.6.14-1.1696_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 gnome-applets - 1:2.13.1-1.i386 requires libgtop-2.0.so.5 gnome-python2-libgtop2 - 2.12.1-7.1.i386 requires libgtop-2.0.so.5 gnome-system-monitor - 2.13.3-1.1.i386 requires libgtop-2.0.so.5 jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.i386 requires libgcjawt.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.i386 requires libgcj.so.6 mesa-libGL - 6.4-5.i386 requires libdrm.so.1 systemtap - 0.5-2.i386 requires libdw.so.1(ELFUTILS_0.116) Broken deps for ia64 ---------------------------------------------------------- gnome-applets - 1:2.13.1-1.ia64 requires libgtop-2.0.so.5()(64bit) gnome-python2-libgtop2 - 2.12.1-7.1.ia64 requires libgtop-2.0.so.5()(64bit) gnome-system-monitor - 2.13.3-1.1.ia64 requires libgtop-2.0.so.5()(64bit) jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) mesa-libGL - 6.4-5.ia64 requires libdrm.so.1()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs systemtap - 0.5-2.ia64 requires libdw.so.1(ELFUTILS_0.116)(64bit) Broken deps for ppc ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 eclipse-bugzilla - 1:0.1.1_fc-5.ppc requires libgcj.so.6 eclipse-cdt - 1:3.0.1-1jpp_1fc.ppc requires libgcj.so.6 eclipse-changelog - 1:2.0.1_fc-22.ppc requires libgcj.so.6 eclipse-ecj - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-jdt - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-pde - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-platform - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 eclipse-pydev - 1:0.9.3_fc-12.ppc requires libgcj.so.6 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 gnome-applets - 1:2.13.1-1.ppc requires libgtop-2.0.so.5 gnome-python2-libgtop2 - 2.12.1-7.1.ppc requires libgtop-2.0.so.5 gnome-system-monitor - 2.13.3-1.1.ppc requires libgtop-2.0.so.5 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.ppc requires libgcjawt.so.6 libswt3-gtk2 - 1:3.1.1-1jpp_9fc.ppc requires libgcj.so.6 mesa-libGL - 6.4-5.ppc requires libdrm.so.1 systemtap - 0.5-2.ppc requires libdw.so.1(ELFUTILS_0.116) Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 gnome-applets - 1:2.13.1-1.ppc64 requires libgtop-2.0.so.5()(64bit) gnome-python2-libgtop2 - 2.12.1-7.1.ppc64 requires libgtop-2.0.so.5()(64bit) gnome-system-monitor - 2.13.3-1.1.ppc64 requires libgtop-2.0.so.5()(64bit) jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) Broken deps for s390 ---------------------------------------------------------- gnome-applets - 1:2.13.1-1.s390 requires libgtop-2.0.so.5 gnome-python2-libgtop2 - 2.12.1-7.1.s390 requires libgtop-2.0.so.5 gnome-system-monitor - 2.13.3-1.1.s390 requires libgtop-2.0.so.5 jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 Broken deps for s390x ---------------------------------------------------------- gnome-applets - 1:2.13.1-1.s390x requires libgtop-2.0.so.5()(64bit) gnome-python2-libgtop2 - 2.12.1-7.1.s390x requires libgtop-2.0.so.5()(64bit) gnome-system-monitor - 2.13.3-1.1.s390x requires libgtop-2.0.so.5()(64bit) jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) libgconf-java - 2.12.0-2.s390x requires libgcj.so.6()(64bit) libgconf-java - 2.12.0-2.s390x requires libcairojava-1.0.so()(64bit) libglade-java - 2.12.0-5.s390x requires libgcj.so.6()(64bit) libglade-java - 2.12.0-5.s390x requires libcairojava-1.0.so()(64bit) libgnome-java - 2.12.0-2.s390x requires libgcj.so.6()(64bit) libgnome-java - 2.12.0-2.s390x requires libcairojava-1.0.so()(64bit) libgtk-java - 2.8.0-7.s390x requires libgcj.so.6()(64bit) libvte-java - 0.11.11-6.3.s390x requires libcairojava-1.0.so()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 eclipse-bugzilla - 1:0.1.1_fc-5.x86_64 requires libgcj.so.6()(64bit) eclipse-cdt - 1:3.0.1-1jpp_1fc.x86_64 requires libgcj.so.6()(64bit) eclipse-changelog - 1:2.0.1_fc-22.x86_64 requires libgcj.so.6()(64bit) eclipse-ecj - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-jdt - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-pde - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-platform - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) eclipse-pydev - 1:0.9.3_fc-12.x86_64 requires libgcj.so.6()(64bit) gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 gnome-applets - 1:2.13.1-1.x86_64 requires libgtop-2.0.so.5()(64bit) gnome-python2-libgtop2 - 2.12.1-7.1.x86_64 requires libgtop-2.0.so.5()(64bit) gnome-system-monitor - 2.13.3-1.1.x86_64 requires libgtop-2.0.so.5()(64bit) jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) libswt3-gtk2 - 1:3.1.1-1jpp_9fc.x86_64 requires libgcjawt.so.6()(64bit) libswt3-gtk2 - 1:3.1.1-1jpp_9fc.x86_64 requires libgcj.so.6()(64bit) mesa-libGL - 6.4-5.i386 requires libdrm.so.1 mesa-libGL - 6.4-5.x86_64 requires libdrm.so.1()(64bit) systemtap - 0.5-2.x86_64 requires libdw.so.1(ELFUTILS_0.116)(64bit) From nphilipp at redhat.com Fri Dec 16 09:29:04 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 16 Dec 2005 10:29:04 +0100 Subject: "GUI gadgets", was: Fedora meeting Mono Half-Way In-Reply-To: <43A1A782.8000506@cornell.edu> References: <43A155CF.4000500@3di.it> <43A1961F.8060706@cornell.edu> <43A1A782.8000506@cornell.edu> Message-ID: <1134725344.11167.5.camel@wombat.tiptoe.de> On Thu, 2005-12-15 at 12:27 -0500, Paul A Houle wrote: > And don't get me started about all the GUI gadgets in FC and RHEL > written in Python that "almost work"... These things don't bother me > since I just edit /etc/sysconfig, but they certainly make Linux look > bad in the eyes of novices. As a maintainer of some of those "GUI gadgets"(*) I'd really like to know what problems you have with them. It's not as if they were faultless, but if there's something -- bugs or missing functionality -- which disturbs you, say what it is (and please put them into Bugzilla). Badmouthing these tools in general ain't gonna help. (*): system-config-date, system-config-nfs, system-config-samba, system-config-services, system-config-users Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From pertusus at free.fr Fri Dec 16 09:33:48 2005 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 16 Dec 2005 10:33:48 +0100 Subject: Shared vs Static (please read) In-Reply-To: <1134720683.2992.16.camel@laptopd505.fenrus.org> References: <1134720683.2992.16.camel@laptopd505.fenrus.org> Message-ID: <20051216093348.GB2910@free.fr> > > http://people.redhat.com/drepper/no_static_linking.html It really depends on what the software is intended to. For system softwares dynamic linking is unavoidable, but for numerical software, where the security/bugfixes/nss/glibc arguments don't hold having statically linked binaries may be of help. I have static binaries that work since 6 or more years and it is very convenient to just run them on any new linux. I still agree that linking statically in general and especially with openssl isn't a good choice. -- Pat From arjan at fenrus.demon.nl Fri Dec 16 09:44:49 2005 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Fri, 16 Dec 2005 10:44:49 +0100 Subject: Shared vs Static (please read) In-Reply-To: <20051216093348.GB2910@free.fr> References: <1134720683.2992.16.camel@laptopd505.fenrus.org> <20051216093348.GB2910@free.fr> Message-ID: <1134726290.2992.25.camel@laptopd505.fenrus.org> On Fri, 2005-12-16 at 10:33 +0100, Patrice Dumas wrote: > > > > http://people.redhat.com/drepper/no_static_linking.html > > It really depends on what the software is intended to. For system softwares > dynamic linking is unavoidable, but for numerical software, where the > security/bugfixes/nss/glibc arguments don't hold having statically linked > binaries may be of help. I have static binaries that work since 6 or > more years and it is very convenient to just run them on any new linux. but as long as you didn't use "evil" libraries, you'd be able to run them on any new linux when they were dynamic linked as well. From pertusus at free.fr Fri Dec 16 09:53:18 2005 From: pertusus at free.fr (Patrice Dumas) Date: Fri, 16 Dec 2005 10:53:18 +0100 Subject: Shared vs Static (please read) In-Reply-To: <1134726290.2992.25.camel@laptopd505.fenrus.org> References: <1134720683.2992.16.camel@laptopd505.fenrus.org> <20051216093348.GB2910@free.fr> <1134726290.2992.25.camel@laptopd505.fenrus.org> Message-ID: <20051216095318.GD3645@free.fr> > > but as long as you didn't use "evil" libraries, you'd be able to run > them on any new linux when they were dynamic linked as well. In practice I always had issues with dynamically linked binaries and not with statically linked ones. -- Pat From Axel.Thimm at ATrpms.net Fri Dec 16 09:54:18 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 16 Dec 2005 10:54:18 +0100 Subject: Installing glib2-2.6.6-1 on FC3? In-Reply-To: <43A27E4C.3050204@redfish-solutions.com> References: <439E6402.6080802@redfish-solutions.com> <20051213114231.GC24704@neu.nirvana> <43A27E4C.3050204@redfish-solutions.com> Message-ID: <20051216095418.GC7680@neu.nirvana> On Fri, Dec 16, 2005 at 01:43:56AM -0700, Philip Prindeville wrote: > Well, I tried the following: > > # rpm -vv -e --nodeps glib2-2.4.8-1.fc3 glib2-devel-2.4.8-1.fc3.i386 > # rpm -v -i http://dl.atrpms.net/all/glib2-2.6.6-1_12.rhfc3.at.i386.rpm > http://dl.atrpms.net/all/libglib-2.0_0-2.6.6-1_12.rhfc3.at.i386.rpm > http://dl.atrpms.net/all/libgthread-2.0_0-2.6.6-1_12.rhfc3.at.i386.rpm > http://dl.atrpms.net/all/libgobject-2.0_0-2.6.6-1_12.rhfc3.at.i386.rpm > http://dl.atrpms.net/all/libgmodule-2.0_0-2.6.6-1_12.rhfc3.at.i386.rpm > http://dl.atrpms.net/all/glib2-devel-2.6.6-1_12.rhfc3.at.i386.rpm --nodeps and -i are bad things. You may be missing required packages now, and the rpm database will show up two glib2 installs, of which one is overwritten by the other. Only use -i with kernels! > and it installed, but... > > Trying to do a build of GDM blew up, and I suspect other things will > eventually over time as well (which reminds me: is there a good way to > exorcise programs that dynamically link to glib2 and make sure they > all perform in a reasonably sane manner?): That's quite a lot. # rpm -q --whatrequires libglib-2.0.so.0 | wc -l 227 And that's only the direct dependecy. There is no sane way to remove glib2's shared libs. > # ./autogen.sh > /usr/bin/gnome-autogen.sh > checking for autoconf >= 2.53... > testing autoconf2.50... not found. > testing autoconf... found 2.59 > checking for automake >= 1.5... > testing automake-1.9... found 1.9.2 > checking for libtool >= 1.4.3... > testing libtoolize... found 1.5.6 > checking for glib-gettext >= 2.2.0... > testing glib-gettextize... not found. > ***Error***: You must have glib-gettext >= 2.2.0 installed > to build GDM. Download the appropriate package for > from your distribution or get the source tarball at > ftp://ftp.gtk.org/pub/gtk/v2.2/glib-2.2.0.tar.gz check out the config.log for the tesing done. > Anyone have a .spec file to build GDM 2.13.0.3 on FC3 or any > suggestions on how to go about that? Pick the rawhide gdm spec and try to upgrade it, it might be easy. -- 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 ivg2 at cornell.edu Fri Dec 16 10:41:45 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 16 Dec 2005 05:41:45 -0500 Subject: "GUI gadgets", was: Fedora meeting Mono Half-Way In-Reply-To: <1134725344.11167.5.camel@wombat.tiptoe.de> References: <43A155CF.4000500@3di.it> <43A1961F.8060706@cornell.edu> <43A1A782.8000506@cornell.edu> <1134725344.11167.5.camel@wombat.tiptoe.de> Message-ID: <43A299E9.2080802@cornell.edu> > As a maintainer of some of those "GUI gadgets"(*) I'd really like to > know what problems you have with them. It's not as if they were > faultless, but if there's something -- bugs or missing functionality -- > which disturbs you, say what it is (and please put them into Bugzilla). > Badmouthing these tools in general ain't gonna help. > > (*): system-config-date, system-config-nfs, system-config-samba, > system-config-services, system-config-users > In the past I have quite often run into python tracebacks (for invalid code), indicating the utilities had not been run through a checker. I think there's a language issue involved here, since this would not happen in a compiled language. However, it would not be fair to criticize now, since they seem to work. The point is that maybe other users have experienced the same, leading to the parent's comment. ---- However, since you bring up bugs... I tried system-config-user, and it says: "The user database cannot be read. This problem is most likely caused by a mismatch in /etc/passwd, and /etc/shadow. This program will exit now". I have no idea whether or not there's a mismatch in /etc/passwd and shadow, but I know that my computer seems to work just fine regardless of any such problems, and the tool should deal with it, and let me edit my users... ---- I also see that system-config-nfs cuts off the two entry boxes on the right when "Server Setting" is selected - the dialog is too small, and you have to resize it manually. --- Also, usability could be improved here, and there. A trivial example is a bug I filed in January (12 months ago): https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145068. A much more serious problem is system-config-packages. Every time I open it it greets me with a friendly message: "/media/cdrecorder1" is not a valid installation source. I don't think I've ever seen this app work - it's been that way for at least 2 years. ... From ivg2 at cornell.edu Fri Dec 16 10:58:35 2005 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 16 Dec 2005 05:58:35 -0500 Subject: "GUI gadgets", was: Fedora meeting Mono Half-Way In-Reply-To: <43A299E9.2080802@cornell.edu> References: <43A155CF.4000500@3di.it> <43A1961F.8060706@cornell.edu> <43A1A782.8000506@cornell.edu> <1134725344.11167.5.camel@wombat.tiptoe.de> <43A299E9.2080802@cornell.edu> Message-ID: <43A29DDB.50408@cornell.edu> > > Also, usability could be improved here, and there. A trivial example > is a bug I filed in January (12 months ago): > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145068. Speaking of bugzillas, why is it that Bugzilla never shows ASSIGNED bugs in "My Bugs"... kind of like this one. It's so annoying - I have to go look for my bugs every time. I guess I should file a bug about it... it will probably be marked ASSIGNED, and I'll never see it again. From thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net Fri Dec 16 11:01:48 2005 From: thias at spam.spam.spam.spam.spam.spam.spam.egg.and.spam.freshrpms.net (Matthias Saou) Date: Fri, 16 Dec 2005 12:01:48 +0100 Subject: bittorrent in core? what frontend? In-Reply-To: <1134721846.28842.166.camel@greebo> References: <1134662961.28842.128.camel@greebo> <20051215202126.GA4210@devserv.devel.redhat.com> <1134721846.28842.166.camel@greebo> Message-ID: <20051216120148.0345c7ec@python2> Alexander Larsson wrote : > On Thu, 2005-12-15 at 15:21 -0500, Bill Nottingham wrote: > > Alexander Larsson (alexl at redhat.com) said: > > > > I don't use bittorrent all that much. What do people think about these > > > two frontends? Are there other interesting ones? > > > > I kept meaning to package gnome-bt for Extras, and kept forgetting. > > So that would be my preference. :) > > One issue with gnome-bt is that it depends on the bittorrent package, > and the bittorrent package already includes the default gui app, so > unless you do some creative packaging you would get two bittorrent UIs > with gnome-bt as the default. The current Extras bittorent package already splits the GUI into a sub-package called "bittorrent-gui", so as long as gnome-bt only requires what is contained in "bittorrent", it should work out fine. Matthias -- Clean custom Red Hat Linux rpm packages : http://freshrpms.net/ Fedora Core release 4 (Stentz) - Linux kernel 2.6.14-1.1653_FC4 Load : 0.54 0.38 0.46 From paul at city-fan.org Fri Dec 16 11:08:32 2005 From: paul at city-fan.org (Paul Howarth) Date: Fri, 16 Dec 2005 11:08:32 +0000 Subject: bittorrent in core? what frontend? In-Reply-To: <20051216120148.0345c7ec@python2> References: <1134662961.28842.128.camel@greebo> <20051215202126.GA4210@devserv.devel.redhat.com> <1134721846.28842.166.camel@greebo> <20051216120148.0345c7ec@python2> Message-ID: <43A2A030.6030404@city-fan.org> Matthias Saou wrote: > Alexander Larsson wrote : > > >>On Thu, 2005-12-15 at 15:21 -0500, Bill Nottingham wrote: >> >>>Alexander Larsson (alexl at redhat.com) said: >> >>>>I don't use bittorrent all that much. What do people think about these >>>>two frontends? Are there other interesting ones? >>> >>>I kept meaning to package gnome-bt for Extras, and kept forgetting. >>>So that would be my preference. :) >> >>One issue with gnome-bt is that it depends on the bittorrent package, >>and the bittorrent package already includes the default gui app, so >>unless you do some creative packaging you would get two bittorrent UIs >>with gnome-bt as the default. > > > The current Extras bittorent package already splits the GUI into a > sub-package called "bittorrent-gui", so as long as gnome-bt only requires > what is contained in "bittorrent", it should work out fine. Probably not actually. Extras has bittorrent 4.2.0 and gnome-bt doesn't work with anything newer than 3.4.2; at least not last time I tried it. http://sourceforge.net/tracker/index.php?func=detail&aid=1189957&group_id=93129&atid=603214 Paul. From linville at redhat.com Fri Dec 16 13:12:21 2005 From: linville at redhat.com (John W. Linville) Date: Fri, 16 Dec 2005 08:12:21 -0500 Subject: kernel-2.6.14-1.1653_FC4.netdev.6? In-Reply-To: <20051215215952.GC4336@rathann.pekin.waw.pl> References: <43A05044.7060803@cygnusx-1.org> <20051215005152.GF26108@rathann.pekin.waw.pl> <20051215010803.GE9801@redhat.com> <20051215162712.GC16712@redhat.com> <20051215215952.GC4336@rathann.pekin.waw.pl> Message-ID: <20051216131221.GA9708@redhat.com> On Thu, Dec 15, 2005 at 10:59:52PM +0100, Dominik 'Rathann' Mierzejewski wrote: > Oh, BTW: any chance of including something like: > CONFIG_STANDALONE=n > CONFIG_PREVENT_FIRMWARE_BUILD=n I'm not sure what these would buy for us? Looks like we would just be cutting-out support for some drivers...? > CONFIG_ACPI_CUSTOM_DSDT=y > CONFIG_ACPI_CUSTOM_DSDT_FILE="/lib/firmware/DSDT.hex" > in Fedora kernel config? These probably send shudders up the spines of anyone involved w/ supporting Fedora kernels. I would not expect to see them enabled in any "official" Fedora kernels anytime soon. > This Acer has a really broken ACPI DSDT and I wish I didn't have to rebuild > every new kernel. You may wish to look here: http://people.redhat.com/linville/kernels/dsdt/ http://people.redhat.com/linville/kernels/fc4/ Please note that the FC4.jwltest kernels do _not_ have the collection of upstream networking fixes that are in the FC4.netdev series. Also, don't blame me if you laptop explodes...ha-ha, only serious. John -- John W. Linville linville at redhat.com From mailinglists at erwinrol.com Fri Dec 16 13:46:25 2005 From: mailinglists at erwinrol.com (Erwin Rol) Date: Fri, 16 Dec 2005 14:46:25 +0100 Subject: OOo on x86_64 Message-ID: <1134740785.22855.2.camel@xpc.home.erwinrol.com> OOo still pulls in mozilla.i386 and libgjc.i386 and those two packages cause problems for me, when I try to install them they seem to collide with the x86_64 versions. Transaction Check Error: file /usr/share/java/libgcj-4.1.0.jar from install of libgcj-4.1.0-0.8 conflicts with file from package libgcj-4.1.0-0.8 Transaction Check Error: file /usr/bin/mozilla from install of mozilla-1.7.12-3 conflicts with file from package mozilla-1.7.12-3 file /usr/share/man/man1/mozilla.1.gz from install of mozilla-1.7.12-3 conflicts with file from package mozilla-1.7.12-3 - Erwin From pozsy at uhulinux.hu Fri Dec 16 13:47:24 2005 From: pozsy at uhulinux.hu (Pozsar Balazs) Date: Fri, 16 Dec 2005 14:47:24 +0100 Subject: Shared vs Static (please read) In-Reply-To: <1134720683.2992.16.camel@laptopd505.fenrus.org> References: <1134720683.2992.16.camel@laptopd505.fenrus.org> Message-ID: <20051216134724.GD20675@ojjektum.uhulinux.hu> Regarding dynamic-vs-static, I was wondering what effects does it have when an app is linked either way. Does anyone know exactly? Also, what about pie-vs-nonpie? thanks, -- pozsy From nphilipp at redhat.com Fri Dec 16 13:54:42 2005 From: nphilipp at redhat.com (Nils Philippsen) Date: Fri, 16 Dec 2005 14:54:42 +0100 Subject: "GUI gadgets", was: Fedora meeting Mono Half-Way In-Reply-To: <43A299E9.2080802@cornell.edu> References: <43A155CF.4000500@3di.it> <43A1961F.8060706@cornell.edu> <43A1A782.8000506@cornell.edu> <1134725344.11167.5.camel@wombat.tiptoe.de> <43A299E9.2080802@cornell.edu> Message-ID: <1134741282.2764.7.camel@wombat.tiptoe.de> On Fri, 2005-12-16 at 05:41 -0500, Ivan Gyurdiev wrote: > However, since you bring up bugs... I tried system-config-user, and it says: > > "The user database cannot be read. This problem is most likely caused by > a mismatch in /etc/passwd, and /etc/shadow. This program will exit now". > > I have no idea whether or not there's a mismatch in /etc/passwd and > shadow, but I know that my computer seems to work just fine regardless > of any such problems, and the tool should deal with it, and let me edit > my users... Can you open a BZ for this one? Please make a copy of your /etc/passwd, group, shadow, gshadow files, edit out any (real) passwords and attach them (marked as private) to that bug. > ---- > I also see that system-config-nfs cuts off the two entry boxes on the > right when "Server Setting" is selected - the dialog is too small, and > you have to resize it manually Fixed in Rawhide. > --- > Also, usability could be improved here, and there. A trivial example is > a bug I filed in January (12 months ago): > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=145068. > > A much more serious problem is system-config-packages. > Every time I open it it greets me with a friendly message: > "/media/cdrecorder1" is not a valid installation source. > I don't think I've ever seen this app work - it's been that way for at > least 2 years. > ... Can't really comment on these two. Nils -- Nils Philippsen / Red Hat / nphilipp at redhat.com "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- B. Franklin, 1759 PGP fingerprint: C4A8 9474 5C4C ADE3 2B8F 656D 47D8 9B65 6951 3011 From katzj at redhat.com Fri Dec 16 14:08:10 2005 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 16 Dec 2005 09:08:10 -0500 Subject: libusual interface [was Re: libusual and ub] In-Reply-To: <20051216001243.446d94e3.zaitcev@redhat.com> References: <20051029193544.096d400e.zaitcev@redhat.com> <20051215031822.GA12020@devserv.devel.redhat.com> <20051214211008.22c1ae47.zaitcev@redhat.com> <20051215053741.GA13787@devserv.devel.redhat.com> <20051215002129.4e9863e0.zaitcev@redhat.com> <1134655233.2864.31.camel@bree.local.net> <20051216001243.446d94e3.zaitcev@redhat.com> Message-ID: <1134742090.2864.65.camel@bree.local.net> On Fri, 2005-12-16 at 00:12 -0800, Pete Zaitcev wrote: > On Thu, 15 Dec 2005 09:00:33 -0500, Jeremy Katz wrote: > > Hey, to be fair, my patch was just probing for the devices once ub > > already got loaded. I ignored the question of "how does ub get loaded" > > since I can guarantee that it happens in anaconda. > > BTW... Just to make sure that we're on the same page, if there's no > working hotplug, you have to load both ub and usb-storage, because > with libusual there is no way to know which is required for the particular > device. In most cases, usb-storage is not needed, and it's a waste of > about 30KB of RAM or so. But I see no (easy) way around it. Right. Or just loading ub in the normal case and see who complains ;) Hmm, actually, would it make sense/be possible to attach the usb ids to usb-storage that we know ub can't drive? Obviously libusual knows that so why not make it a little more explicit? > > [...] So if we're going to build libusual > > in statically, having the sysfs method to change the bias becomes > > incredibly important (... as then I can just write to the file from the > > loader and not worry about it) > > OK, that was a half an hour job. See attached, I'll ask Dave to include > it and send it to upstream now. Note that there's no bind/unbind here, > so it has to be set before the back end drivers are loaded. Looks good to me. > Out of curiousity, what part of the code makes these decisions: > a) If to load USB storage drivers at all, whatever they are We do a kudzu probe for cd, hd or floppy devices on the usb bus -- which basically looks for devices of usbclass 8. > b) What of the available CD-ROMs has the ISO We look just on things that are CDs (kudzu checks the subclass code) and try to mount them and see if there's anything there. If we find what we're looking for, we pass that information on to the second stage of the installer and off we go. > I would like to look. The kudzu code is kudzu/usb.c, the first stage of the installer is under anaconda/loader2/ with the probing code in usb.c and the mounting code scattered around a bit more. Jeremy From pozsy at uhulinux.hu Fri Dec 16 14:22:44 2005 From: pozsy at uhulinux.hu (Pozsar Balazs) Date: Fri, 16 Dec 2005 15:22:44 +0100 Subject: Shared vs Static (please read) In-Reply-To: <20051216134724.GD20675@ojjektum.uhulinux.hu> References: <1134720683.2992.16.camel@laptopd505.fenrus.org> <20051216134724.GD20675@ojjektum.uhulinux.hu> Message-ID: <20051216142243.GE20675@ojjektum.uhulinux.hu> On Fri, Dec 16, 2005 at 02:47:24PM +0100, Pozsar Balazs wrote: > > Regarding dynamic-vs-static, I was wondering what effects does it have > when an app is linked either way. Does anyone know exactly? Err... I meant what effect _on execution speed_ does it have? -- pozsy From clovis at agr.unicamp.br Fri Dec 16 15:34:11 2005 From: clovis at agr.unicamp.br (Clovis Tristao) Date: Fri, 16 Dec 2005 13:34:11 -0200 Subject: Yum Error In-Reply-To: <20051213015917.GA14560@us.ibm.com> References: <20051213015917.GA14560@us.ibm.com> Message-ID: <43A2DE73.4050802@agr.unicamp.br> Hi, I've to update my system using yum -y update, but appears this errors: Error: Missing Dependency: dbus = 0.50-1 is needed by package dbus-qt Error: Missing Dependency: libgtop-2.0.so.5 is needed by package gnome-system-monitor Error: Missing Dependency: libgtop-2.0.so.5 is needed by package gnome-applets Error: Missing Dependency: libdbus-1.so.1 is needed by package dbus-qt Error: Missing Dependency: libdrm.so.1 is needed by package mesa-libGL Error: Missing Dependency: libgcj.so.6 is needed by package eclipse-ecj I need to update php 5.1.1 w/ php-xml 5.1.1. Tks any info/help, Cl?vis From clovis at agr.unicamp.br Fri Dec 16 15:38:46 2005 From: clovis at agr.unicamp.br (Clovis Tristao) Date: Fri, 16 Dec 2005 13:38:46 -0200 Subject: Yum Error-HELP Message-ID: <43A2DF86.8070409@agr.unicamp.br> Hi, I've to update my system using yum -y update, but appears this errors: Error: Missing Dependency: dbus = 0.50-1 is needed by package dbus-qt Error: Missing Dependency: libgtop-2.0.so.5 is needed by package gnome-system-monitor Error: Missing Dependency: libgtop-2.0.so.5 is needed by package gnome-applets Error: Missing Dependency: libdbus-1.so.1 is needed by package dbus-qt Error: Missing Dependency: libdrm.so.1 is needed by package mesa-libGL Error: Missing Dependency: libgcj.so.6 is needed by package eclipse-ecj I need to update php 5.1.1 w/ php-xml 5.1.1. Tks any info/help, Cl?vis -- Clovis Tristao - UNICAMP/Faculdade de Engenharia Agricola Administrador de Redes - Secao de Informatica (SINFO) E-mail: mailto:clovis at agr.unicamp.br http://www.agr.unicamp.br Fone(0xx19) 37881031-37881038 ou FAX(55xx19) 37881005/37881010 From casimiro.barreto at gmail.com Fri Dec 16 15:52:25 2005 From: casimiro.barreto at gmail.com (Casimiro de Almeida Barreto) Date: Fri, 16 Dec 2005 13:52:25 -0200 Subject: Yum Error-HELP In-Reply-To: <43A2DF86.8070409@agr.unicamp.br> References: <43A2DF86.8070409@agr.unicamp.br> Message-ID: <43A2E2B9.5010601@gmail.com> I made it the "punk way": Created a /var/lib/legacy dir Made a copy of the libgtop-2.0.so.5... to legacy and repeated the procedure for the required dependencies. Downloaded the libgtop and other packages from download.fedora.redhat.com (/pub/fedora/linux/core/development/i386/Fedora/RPMS) Forced installed them (rpm -Uvh --force --nodeps) Then restored the links to the packages in the legacy dir (cd /usr/lib; ln -s legacy/libgtop... libgtop-2.0.so.5) for all the dependencies. Then it runs OK. Remember, for dbus you have to backup the dbus-1.0 dir... not only the libs Best regards, Casimiro Remember: rawhide eats babies... Clovis Tristao wrote: > Hi, > > I've to update my system using yum -y update, but appears this errors: > > Error: Missing Dependency: dbus = 0.50-1 is needed by package dbus-qt > Error: Missing Dependency: libgtop-2.0.so.5 is needed by package > gnome-system-monitor > Error: Missing Dependency: libgtop-2.0.so.5 is needed by package > gnome-applets > Error: Missing Dependency: libdbus-1.so.1 is needed by package dbus-qt > Error: Missing Dependency: libdrm.so.1 is needed by package mesa-libGL > Error: Missing Dependency: libgcj.so.6 is needed by package eclipse-ecj > > I need to update php 5.1.1 w/ php-xml 5.1.1. > Tks any info/help, > > Cl?vis > From alexl at redhat.com Fri Dec 16 15:54:59 2005 From: alexl at redhat.com (Alexander Larsson) Date: Fri, 16 Dec 2005 16:54:59 +0100 Subject: bittorrent in core? what frontend? In-Reply-To: <20051216120148.0345c7ec@python2> References: <1134662961.28842.128.camel@greebo> <20051215202126.GA4210@devserv.devel.redhat.com> <1134721846.28842.166.camel@greebo> <20051216120148.0345c7ec@python2> Message-ID: <1134748499.28842.200.camel@greebo> On Fri, 2005-12-16 at 12:01 +0100, Matthias Saou wrote: > Alexander Larsson wrote : > > > On Thu, 2005-12-15 at 15:21 -0500, Bill Nottingham wrote: > > > Alexander Larsson (alexl at redhat.com) said: > > > > > > I don't use bittorrent all that much. What do people think about these > > > > two frontends? Are there other interesting ones? > > > > > > I kept meaning to package gnome-bt for Extras, and kept forgetting. > > > So that would be my preference. :) > > > > One issue with gnome-bt is that it depends on the bittorrent package, > > and the bittorrent package already includes the default gui app, so > > unless you do some creative packaging you would get two bittorrent UIs > > with gnome-bt as the default. > > The current Extras bittorent package already splits the GUI into a > sub-package called "bittorrent-gui", so as long as gnome-bt only requires > what is contained in "bittorrent", it should work out fine. It might not have to be in the default install, but it has to be in core, as they build from the same SRPM. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an otherworldly misogynist rock star with a robot buddy named Sparky. She's an elegant belly-dancing journalist from aristocratic European stock. They fight crime! From alexl at redhat.com Fri Dec 16 15:56:00 2005 From: alexl at redhat.com (Alexander Larsson) Date: Fri, 16 Dec 2005 16:56:00 +0100 Subject: bittorrent in core? what frontend? In-Reply-To: <43A2A030.6030404@city-fan.org> References: <1134662961.28842.128.camel@greebo> <20051215202126.GA4210@devserv.devel.redhat.com> <1134721846.28842.166.camel@greebo> <20051216120148.0345c7ec@python2> <43A2A030.6030404@city-fan.org> Message-ID: <1134748560.28842.202.camel@greebo> On Fri, 2005-12-16 at 11:08 +0000, Paul Howarth wrote: > Matthias Saou wrote: > > Alexander Larsson wrote : > > > > > >>On Thu, 2005-12-15 at 15:21 -0500, Bill Nottingham wrote: > >> > >>>Alexander Larsson (alexl at redhat.com) said: > >> > >>>>I don't use bittorrent all that much. What do people think about these > >>>>two frontends? Are there other interesting ones? > >>> > >>>I kept meaning to package gnome-bt for Extras, and kept forgetting. > >>>So that would be my preference. :) > >> > >>One issue with gnome-bt is that it depends on the bittorrent package, > >>and the bittorrent package already includes the default gui app, so > >>unless you do some creative packaging you would get two bittorrent UIs > >>with gnome-bt as the default. > > > > > > The current Extras bittorent package already splits the GUI into a > > sub-package called "bittorrent-gui", so as long as gnome-bt only requires > > what is contained in "bittorrent", it should work out fine. > > Probably not actually. Extras has bittorrent 4.2.0 and gnome-bt doesn't > work with anything newer than 3.4.2; at least not last time I tried it. > > http://sourceforge.net/tracker/index.php?func=detail&aid=1189957&group_id=93129&atid=603214 I didn't really do much testing, but http://people.redhat.com/alexl/files/gnome-bt-0.0.22-1.noarch.rpm seemed to work fine with current bittorrent from extras. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an ungodly chivalrous filmmaker plagued by the memory of his family's brutal murder. She's a sharp-shooting tomboy stripper from aristocratic European stock. They fight crime! From alexl at redhat.com Fri Dec 16 16:00:37 2005 From: alexl at redhat.com (Alexander Larsson) Date: Fri, 16 Dec 2005 17:00:37 +0100 Subject: Shared vs Static (please read) In-Reply-To: <20051216142243.GE20675@ojjektum.uhulinux.hu> References: <1134720683.2992.16.camel@laptopd505.fenrus.org> <20051216134724.GD20675@ojjektum.uhulinux.hu> <20051216142243.GE20675@ojjektum.uhulinux.hu> Message-ID: <1134748837.28842.205.camel@greebo> On Fri, 2005-12-16 at 15:22 +0100, Pozsar Balazs wrote: > On Fri, Dec 16, 2005 at 02:47:24PM +0100, Pozsar Balazs wrote: > > > > Regarding dynamic-vs-static, I was wondering what effects does it have > > when an app is linked either way. Does anyone know exactly? > > Err... I meant what effect _on execution speed_ does it have? A statically linked application by itself with a lot of memory might execute a bit faster. However, if all apps were statically linked then all library code would be duplicated in each application leading to general system slowdown due to more swapping and worse cache behaviour. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a scrappy voodoo Green Beret possessed of the uncanny powers of an insect. She's a vivacious paranoid traffic cop with a birthmark shaped like Liberty's torch. They fight crime! From arjan at fenrus.demon.nl Fri Dec 16 16:50:15 2005 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Fri, 16 Dec 2005 17:50:15 +0100 Subject: Shared vs Static (please read) In-Reply-To: <20051216142243.GE20675@ojjektum.uhulinux.hu> References: <1134720683.2992.16.camel@laptopd505.fenrus.org> <20051216134724.GD20675@ojjektum.uhulinux.hu> <20051216142243.GE20675@ojjektum.uhulinux.hu> Message-ID: <1134751815.2992.48.camel@laptopd505.fenrus.org> On Fri, 2005-12-16 at 15:22 +0100, Pozsar Balazs wrote: > On Fri, Dec 16, 2005 at 02:47:24PM +0100, Pozsar Balazs wrote: > > > > Regarding dynamic-vs-static, I was wondering what effects does it have > > when an app is linked either way. Does anyone know exactly? > > Err... I meant what effect _on execution speed_ does it have? on x86 you pay a small overhead (single digit percents nowadays), on x64 it's mostly free.... in the single use case in the multiple-use case there is actually an advantage due to more efficient use of L1/L2 cache From dhollis at davehollis.com Fri Dec 16 17:41:02 2005 From: dhollis at davehollis.com (David Hollis) Date: Fri, 16 Dec 2005 12:41:02 -0500 Subject: Yum Error-HELP In-Reply-To: <43A2DF86.8070409@agr.unicamp.br> References: <43A2DF86.8070409@agr.unicamp.br> Message-ID: <1134754862.30209.14.camel@dhollis-lnx.sunera.com> On Fri, 2005-12-16 at 13:38 -0200, Clovis Tristao wrote: > Hi, > > I've to update my system using yum -y update, but appears this errors: > > Error: Missing Dependency: dbus = 0.50-1 is needed by package dbus-qt dbus-qt is now gone. rpm -e dbus-qt to get rid of it and dbus will be able to upgrade. > Error: Missing Dependency: libgtop-2.0.so.5 is needed by package > gnome-system-monitor > Error: Missing Dependency: libgtop-2.0.so.5 is needed by package > gnome-applets I had this today as well. Try --exclude=libgtop2\* > Error: Missing Dependency: libdbus-1.so.1 is needed by package dbus-qt > Error: Missing Dependency: libdrm.so.1 is needed by package mesa-libGL > Error: Missing Dependency: libgcj.so.6 is needed by package eclipse-ecj > These guys need a rebuild to get their deps fixed up. I was able to --exclude=libdrm\* The eclipse part may bite you. I just had to work around all of the java components while they were in flux. Only a few remain to be fixed up. -- David Hollis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From dgregor at redhat.com Fri Dec 16 18:49:49 2005 From: dgregor at redhat.com (Dennis Gregorovic) Date: Fri, 16 Dec 2005 13:49:49 -0500 Subject: OOo on x86_64 In-Reply-To: <1134740785.22855.2.camel@xpc.home.erwinrol.com> References: <1134740785.22855.2.camel@xpc.home.erwinrol.com> Message-ID: <1134758989.14717.9.camel@localhost.localdomain> On Fri, 2005-12-16 at 14:46 +0100, Erwin Rol wrote: > OOo still pulls in mozilla.i386 and libgjc.i386 and those two packages > cause problems for me, when I try to install them they seem to collide > with the x86_64 versions. > > Transaction Check Error: file /usr/share/java/libgcj-4.1.0.jar from > install of libgcj-4.1.0-0.8 conflicts with file from package > libgcj-4.1.0-0.8 > > Transaction Check Error: file /usr/bin/mozilla from install of > mozilla-1.7.12-3 conflicts with file from package mozilla-1.7.12-3 > file /usr/share/man/man1/mozilla.1.gz from install of mozilla-1.7.12-3 > conflicts with file from package mozilla-1.7.12-3 > > > - Erwin Thanks for the update. Caolon is working on the fix. -- Dennis From overholt at redhat.com Fri Dec 16 20:08:41 2005 From: overholt at redhat.com (Andrew Overholt) Date: Fri, 16 Dec 2005 15:08:41 -0500 Subject: Yum Error-HELP In-Reply-To: <1134754862.30209.14.camel@dhollis-lnx.sunera.com> References: <43A2DF86.8070409@agr.unicamp.br> <1134754862.30209.14.camel@dhollis-lnx.sunera.com> Message-ID: <1134763721.3212.3.camel@tophat.toronto.redhat.com> On Fri, 2005-12-16 at 12:41 -0500, David Hollis wrote: > On Fri, 2005-12-16 at 13:38 -0200, Clovis Tristao wrote: > > Error: Missing Dependency: libdbus-1.so.1 is needed by package dbus-qt > > Error: Missing Dependency: libdrm.so.1 is needed by package mesa-libGL > > Error: Missing Dependency: libgcj.so.6 is needed by package eclipse-ecj > > > > These guys need a rebuild to get their deps fixed up. I was able to > --exclude=libdrm\* > > The eclipse part may bite you. I just had to work around all of the > java components while they were in flux. Only a few remain to be fixed > up. Yeah, we're working on it and we're almost there. Andrew From denis at poolshark.org Fri Dec 16 20:40:56 2005 From: denis at poolshark.org (Denis Leroy) Date: Fri, 16 Dec 2005 12:40:56 -0800 Subject: Shared vs Static (please read) In-Reply-To: <1134748837.28842.205.camel@greebo> References: <1134720683.2992.16.camel@laptopd505.fenrus.org> <20051216134724.GD20675@ojjektum.uhulinux.hu> <20051216142243.GE20675@ojjektum.uhulinux.hu> <1134748837.28842.205.camel@greebo> Message-ID: <43A32658.3090103@poolshark.org> Alexander Larsson wrote: > On Fri, 2005-12-16 at 15:22 +0100, Pozsar Balazs wrote: > >>On Fri, Dec 16, 2005 at 02:47:24PM +0100, Pozsar Balazs wrote: >> >>>Regarding dynamic-vs-static, I was wondering what effects does it have >>>when an app is linked either way. Does anyone know exactly? >> >>Err... I meant what effect _on execution speed_ does it have? > > > A statically linked application by itself with a lot of memory might > execute a bit faster. However, if all apps were statically linked then > all library code would be duplicated in each application leading to > general system slowdown due to more swapping and worse cache behaviour. Exactly. This is particularly true of a desktop environment with gnome applications which generally share a lot of dynamic libraries. The hotter cache results in much faster startup times and response time for gnome apps. From dominik at greysector.net Fri Dec 16 22:56:17 2005 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Fri, 16 Dec 2005 23:56:17 +0100 Subject: kernel-2.6.14-1.1653_FC4.netdev.6? In-Reply-To: <20051216131221.GA9708@redhat.com> References: <43A05044.7060803@cygnusx-1.org> <20051215005152.GF26108@rathann.pekin.waw.pl> <20051215010803.GE9801@redhat.com> <20051215162712.GC16712@redhat.com> <20051215215952.GC4336@rathann.pekin.waw.pl> <20051216131221.GA9708@redhat.com> Message-ID: <20051216225617.GC4376@rathann.pekin.waw.pl> On Friday, 16 December 2005 at 14:12, John W. Linville wrote: > On Thu, Dec 15, 2005 at 10:59:52PM +0100, Dominik 'Rathann' Mierzejewski wrote: > > > Oh, BTW: any chance of including something like: > > CONFIG_STANDALONE=n > > CONFIG_PREVENT_FIRMWARE_BUILD=n > > I'm not sure what these would buy for us? Looks like we would just > be cutting-out support for some drivers...? AFAIR without them the following are inactive. > > CONFIG_ACPI_CUSTOM_DSDT=y > > CONFIG_ACPI_CUSTOM_DSDT_FILE="/lib/firmware/DSDT.hex" > > in Fedora kernel config? > > These probably send shudders up the spines of anyone involved w/ > supporting Fedora kernels. I would not expect to see them enabled > in any "official" Fedora kernels anytime soon. ACK. Note to myself: tell everyone NOT to buy Acer laptops if you want Linux on it. > > This Acer has a really broken ACPI DSDT and I wish I didn't have to rebuild > > every new kernel. > > You may wish to look here: > > http://people.redhat.com/linville/kernels/dsdt/ > http://people.redhat.com/linville/kernels/fc4/ Thanks. > Please note that the FC4.jwltest kernels do _not_ have the collection > of upstream networking fixes that are in the FC4.netdev series. > Also, don't blame me if you laptop explodes...ha-ha, only serious. :) Anyway, until "DSDT in initrd" patch becomes part of FC kernels, I might as well stick to what I do, because changing a few config params is far less invasive and time consuming than applying a patch to released kernels. Regards, R. -- APT/YUM RPM repository for Fedora Core http://rpm.greysector.net/ mpg321, xmp, faad2, lame, mad, *mplayer*, rdesktop, tin, xvid, mks, mutt "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From rodd at clarkson.id.au Fri Dec 16 23:07:08 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Sat, 17 Dec 2005 10:07:08 +1100 Subject: rawhide report: 20051216 changes In-Reply-To: <200512160912.jBG9CV5E009998@porkchop.devel.redhat.com> References: <200512160912.jBG9CV5E009998@porkchop.devel.redhat.com> Message-ID: <1134774429.3099.5.camel@localhost.localdomain> > kernel-2.6.14-1.1767_FC5 > ------------------------ > * Thu Dec 15 2005 Dave Jones > - 2.6.15-rc5-git5 > > * Wed Dec 14 2005 Dave Jones > - 2.6.15-rc5-git4 > - Try 'optimise for size' again. > - Silence noisy CD drives that spew msgs when probed whilst empty. > > * Tue Dec 13 2005 Dave Jones > - 2.6.15-rc5-git3 > - Use MMIO instead of PIO for 8139too FC5 seems keen to get me to run the smp kernel (I'm on a uniprocessor machine without hyperthreading). I've noticed with this update (since the smp kernel runs - the one that came with the original install didn't) that the smp kernel seems to be noticeably slower than the non-smp kernel. > selinux-policy-2.1.6-4 > ---------------------- > * Wed Dec 14 2005 Dan Walsh 2.1.5-4 > - Fixes to allow automount to use portmap > - Fixes to start kernel in s0-s15:c0.c255 I'm not getting any of the kernels installed to boot without adding a selinux=0 to the boot process. I don't think this is kernel related, but something to do with selinux. The kernels get to the point where X starts and the cursor appears and then nothing else happens. Dropping to the vt (CTRL-ALT-BACKSPACE) shows the hardware initialized, and then no further progress. Rodd -- "It's a fine line between denial and faith. It's much better on my side" From rodd at clarkson.id.au Fri Dec 16 23:12:01 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Sat, 17 Dec 2005 10:12:01 +1100 Subject: rawhide report: 20051212 changes In-Reply-To: <200512121122.jBCBMh3T002898@porkchop.devel.redhat.com> References: <200512121122.jBCBMh3T002898@porkchop.devel.redhat.com> Message-ID: <1134774721.3099.9.camel@localhost.localdomain> On Mon, 2005-12-12 at 06:22 -0500, Build System wrote: > gnome-panel-2.13.2-1.1 > ---------------------- > * Fri Dec 09 2005 Jesse Keating > - rebuilt Hmmm, not sure if this is where this problem started, but I think it might be. I'm using transparency in my panels. The Applications/Places/Desktop menu and the Window Selector applet are now both putting a black background (with black text) when you have any transparency applied to the color. If I set the color to solid, then they look fine, but apply any transparency at all and the background turns black and you can't read the text for these items in the panel. Rodd -- "It's a fine line between denial and faith. It's much better on my side" From mpeters at mac.com Fri Dec 16 23:24:26 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 16 Dec 2005 15:24:26 -0800 Subject: bittorrent in core? what frontend? In-Reply-To: <43A1B9BD.2080306@insitesinc.com> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A1B9BD.2080306@insitesinc.com> Message-ID: <1134775467.3032.10.camel@locolhost.localdomain> On Thu, 2005-12-15 at 12:45 -0600, Michael Favia wrote: > > While i agree with j5 statemnt on simplicity i disagree that closing the > torrent "defeats" the purpose. Even if individuals close the torrent > after download they still supported the torrent throughout their > download. (even if U/D ratios are biased). While it's only decent to > wait till you have a 1:1 ratio imo it is perfectly acceptable to get > what you need and mosey on if you'd like. Yup - a lot of users have really restricted upload. I use bt on a headless box - through a torrent file into ~/torrent/active/ and it goes - I try to leave them in there for at least a week or so (though never more than 3 at once) because I can, it doesn't bother me to seed - and I know some people have really limited upload and it isn't reasonable to expect everyone to seed until 1:1 Those who have bandwidth can seed beyond 1:1 to compensate. From mpeters at mac.com Fri Dec 16 23:27:30 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 16 Dec 2005 15:27:30 -0800 Subject: bittorrent in core? what frontend? In-Reply-To: References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> Message-ID: <1134775651.3032.14.camel@locolhost.localdomain> On Thu, 2005-12-15 at 16:23 -0500, Jack Tanner wrote: > John (J5) Palmieri wrote: > > Not sure but I think the one in core should be the simplest. Click on > > a .torrent file and a nice little progress bar pops up to tell you the > > status and perhaps sits in the notification area. By all means though, > > get Azureus to work and find someone to package it into extras. > > I don't mean to get into "my favorite client is X" debate, but if we're > picking something for core, I'd argue for picking a client that people > really love.[1] I've never used Azureus, but by that reasoning, since > Azureus is regularly on sf.net's most downloaded/highest activity lists, > it's a good choice. The "safe but boring" default client is a bad choice. Fedora focuses on Gnome. For UI consistency - a gnome client is best imho. A non gnome gtk client is acceptable. Java - I'm not a big fan. I've never tried Azureus - but the only operating system I've ever used where gui java apps look even halfway acceptable is OS X. From mpeters at mac.com Fri Dec 16 23:31:07 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 16 Dec 2005 15:31:07 -0800 Subject: bittorrent in core? what frontend? In-Reply-To: <1134748499.28842.200.camel@greebo> References: <1134662961.28842.128.camel@greebo> <20051215202126.GA4210@devserv.devel.redhat.com> <1134721846.28842.166.camel@greebo> <20051216120148.0345c7ec@python2> <1134748499.28842.200.camel@greebo> Message-ID: <1134775868.3032.16.camel@locolhost.localdomain> On Fri, 2005-12-16 at 16:54 +0100, Alexander Larsson wrote: > > It might not have to be in the default install, but it has to be in > core, as they build from the same SRPM. No it doesn't. cdrdao is in core, gcdmaster is not - the source is in the same tarball. From katzj at redhat.com Fri Dec 16 23:35:33 2005 From: katzj at redhat.com (Jeremy Katz) Date: Fri, 16 Dec 2005 18:35:33 -0500 Subject: rawhide report: 20051216 changes In-Reply-To: <1134774429.3099.5.camel@localhost.localdomain> References: <200512160912.jBG9CV5E009998@porkchop.devel.redhat.com> <1134774429.3099.5.camel@localhost.localdomain> Message-ID: <1134776133.21009.12.camel@bree.local.net> On Sat, 2005-12-17 at 10:07 +1100, Rodd Clarkson wrote: > > kernel-2.6.14-1.1767_FC5 > > ------------------------ > > * Thu Dec 15 2005 Dave Jones > > - 2.6.15-rc5-git5 > > > > * Wed Dec 14 2005 Dave Jones > > - 2.6.15-rc5-git4 > > - Try 'optimise for size' again. > > - Silence noisy CD drives that spew msgs when probed whilst empty. > > > > * Tue Dec 13 2005 Dave Jones > > - 2.6.15-rc5-git3 > > - Use MMIO instead of PIO for 8139too > > FC5 seems keen to get me to run the smp kernel (I'm on a uniprocessor > machine without hyperthreading). I've noticed with this update (since > the smp kernel runs - the one that came with the original install > didn't) that the smp kernel seems to be noticeably slower than the > non-smp kernel. Do you have a processor which supports NX (see /proc/cpuinfo). If so, we were defaulting to installing kernel-smp for test1. Unfortunately, that has turned up some problems and so won't be the case in test2 or later. Jeremy From thuforuk at yahoo.co.uk Fri Dec 16 23:39:42 2005 From: thuforuk at yahoo.co.uk (Dariusz J. Garbowski) Date: Fri, 16 Dec 2005 23:39:42 +0000 Subject: bittorrent in core? what frontend? In-Reply-To: <1134775651.3032.14.camel@locolhost.localdomain> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <1134775651.3032.14.camel@locolhost.localdomain> Message-ID: <43A3503E.7010105@yahoo.co.uk> On 12/16/2005 11:27 PM, Michael A. Peters wrote: > On Thu, 2005-12-15 at 16:23 -0500, Jack Tanner wrote: > >>John (J5) Palmieri wrote: >> >>>Not sure but I think the one in core should be the simplest. Click on >>>a .torrent file and a nice little progress bar pops up to tell you the >>>status and perhaps sits in the notification area. By all means though, >>>get Azureus to work and find someone to package it into extras. >> >>I don't mean to get into "my favorite client is X" debate, but if we're >>picking something for core, I'd argue for picking a client that people >>really love.[1] I've never used Azureus, but by that reasoning, since >>Azureus is regularly on sf.net's most downloaded/highest activity lists, >>it's a good choice. The "safe but boring" default client is a bad choice. > > > Fedora focuses on Gnome. > For UI consistency - a gnome client is best imho. > A non gnome gtk client is acceptable. Funny that Azureus uses SWT toolkit, which in turn uses GTK :-) > Java - I'm not a big fan. I've never tried Azureus - but the only > operating system I've ever used where gui java apps look even halfway > acceptable is OS X. See Eclipse (SWT as well). Granted, I'm not a big fan of many Java GUI apps -- people go too wild with "app has to look their way", which ends up in too many apps looking different :( (And I'm a Java developer myself.) Regards, Dariusz ___________________________________________________________ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com From mpeters at mac.com Fri Dec 16 23:48:39 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 16 Dec 2005 15:48:39 -0800 Subject: bittorrent in core? what frontend? In-Reply-To: <43A3503E.7010105@yahoo.co.uk> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <1134775651.3032.14.camel@locolhost.localdomain> <43A3503E.7010105@yahoo.co.uk> Message-ID: <1134776919.3032.20.camel@locolhost.localdomain> On Fri, 2005-12-16 at 23:39 +0000, Dariusz J. Garbowski wrote: > > Funny that Azureus uses SWT toolkit, which in turn uses GTK :-) OK. There's a good chance I don't know what I'm talking about. I don't think I've ever used a Java gui app that uses gtk. If it uses gtk - that's a definite + From ihok at hotmail.com Sat Dec 17 00:05:41 2005 From: ihok at hotmail.com (Jack Tanner) Date: Fri, 16 Dec 2005 19:05:41 -0500 Subject: funny user moment (and perhaps a bug) In-Reply-To: References: <604aa7910512131458o444fd787o73302d58233da713@mail.gmail.com> Message-ID: Jack Tanner wrote: >> If there is a bug here it probably has to do with the fact that the >> cd-player application itself gets out of sync across multiple >> invocations. Can you reproduce this by starting 2 gnome-cd instances >> in the same gnome session? > > Yes. > 1. Starting 1 gnome-cd instance, play the CD. > 2. Start another gnome-cd. It won't catch that the CD is playing. I was gonna file a bug about this, but could someone running Rawhide reproduce this first? FC4 is on 2.10.0, and that's probably too old to file about... From wtogami at redhat.com Sat Dec 17 00:57:25 2005 From: wtogami at redhat.com (Warren Togami) Date: Fri, 16 Dec 2005 19:57:25 -0500 Subject: bittorrent in core? what frontend? In-Reply-To: <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> Message-ID: <43A36275.40609@redhat.com> Jeff Spaleta wrote: > On 12/15/05, John (J5) Palmieri wrote: >> Not sure but I think the one in core should be the simplest. Click on >> a .torrent file and a nice little progress bar pops up to tell you the >> status and perhaps sits in the notification area. > > I think notification area item is going to be pretty important. Isn't > the whole point of a bittorrent client to act as a peer even when the > download is completed? If all people are doing is leeching and then > turning off their own torrent nodes that sort of defeats the purpose > of the peering concept. I think you'll definitely want to continue to > inform the desktop user that the bittorrent node is still active and > is uploading to other peers aftger the download is complete. I don't > think you want that going on in the background without some visual que > to remind people. > > -jef > The biggest problem with this entire idea is that it wont work for users by default, because our default security configuration will block incoming connections, and more users these days are behind NAT. Warren Togami wtogami at redhat.com From selinux at gmail.com Sat Dec 17 02:17:41 2005 From: selinux at gmail.com (Tom London) Date: Fri, 16 Dec 2005 18:17:41 -0800 Subject: rawhide report: 20051216 changes In-Reply-To: <1134774429.3099.5.camel@localhost.localdomain> References: <200512160912.jBG9CV5E009998@porkchop.devel.redhat.com> <1134774429.3099.5.camel@localhost.localdomain> Message-ID: <4c4ba1530512161817v96bb479l7e5e78421df91656@mail.gmail.com> On 12/16/05, Rodd Clarkson wrote: > > > kernel-2.6.14-1.1767_FC5 > > ------------------------ > > * Thu Dec 15 2005 Dave Jones > > - 2.6.15-rc5-git5 > > > > * Wed Dec 14 2005 Dave Jones > > - 2.6.15-rc5-git4 > > - Try 'optimise for size' again. > > - Silence noisy CD drives that spew msgs when probed whilst empty. > > > > * Tue Dec 13 2005 Dave Jones > > - 2.6.15-rc5-git3 > > - Use MMIO instead of PIO for 8139too > > FC5 seems keen to get me to run the smp kernel (I'm on a uniprocessor > machine without hyperthreading). I've noticed with this update (since > the smp kernel runs - the one that came with the original install > didn't) that the smp kernel seems to be noticeably slower than the > non-smp kernel. > > > > selinux-policy-2.1.6-4 > > ---------------------- > > * Wed Dec 14 2005 Dan Walsh 2.1.5-4 > > - Fixes to allow automount to use portmap > > - Fixes to start kernel in s0-s15:c0.c255 > > I'm not getting any of the kernels installed to boot without adding a > selinux=0 to the boot process. I don't think this is kernel related, > but something to do with selinux. The kernels get to the point where X > starts and the cursor appears and then nothing else happens. Dropping > to the vt (CTRL-ALT-BACKSPACE) shows the hardware initialized, and then > no further progress. > There is a problem with today's selinux-policy. Revert to the prior one. Believe it will be fixed in tomorrow's rawhide. > > Rodd > > -- > "It's a fine line between denial and faith. > It's much better on my side" > tom -- Tom London From notting at redhat.com Sat Dec 17 06:53:04 2005 From: notting at redhat.com (Bill Nottingham) Date: Sat, 17 Dec 2005 01:53:04 -0500 Subject: libusual interface [was Re: libusual and ub] In-Reply-To: <20051216001243.446d94e3.zaitcev@redhat.com> References: <20051029193544.096d400e.zaitcev@redhat.com> <20051215031822.GA12020@devserv.devel.redhat.com> <20051214211008.22c1ae47.zaitcev@redhat.com> <20051215053741.GA13787@devserv.devel.redhat.com> <20051215002129.4e9863e0.zaitcev@redhat.com> <1134655233.2864.31.camel@bree.local.net> <20051216001243.446d94e3.zaitcev@redhat.com> Message-ID: <20051217065304.GA24500@devserv.devel.redhat.com> Pete Zaitcev (zaitcev at redhat.com) said: > > [...] So if we're going to build libusual > > in statically, having the sysfs method to change the bias becomes > > incredibly important (... as then I can just write to the file from the > > loader and not worry about it) > > OK, that was a half an hour job. See attached, I'll ask Dave to include > it and send it to upstream now. Note that there's no bind/unbind here, > so it has to be set before the back end drivers are loaded. So... what happens if you have something using one of the backends loaded,and you want to change what you're using for the second USB device? I still think we should just use module aliases and either don't auto-bind, or separate the aliases by which driver is best. > With ub, it is not obvious that the media is indeed a CD-ROM (or a DVD). > Since ub issues no MODE SENSE command, everything is an array of blocks. > So, suppose that everything works, how would you know that we're > installing from /dev/uba or whatever? Do you try to read a header > from everything that looks vaguely like a block device? That may cause > interesting effects if you are attached to a SAN, so obviously you do not. > Very curious. Generally, the code expects CD-ROMS to be detectable as such - this is easy enough with IDE or SCSI (and SCSI-using-things.) Bill From notting at redhat.com Sat Dec 17 06:54:17 2005 From: notting at redhat.com (Bill Nottingham) Date: Sat, 17 Dec 2005 01:54:17 -0500 Subject: libusual interface [was Re: libusual and ub] In-Reply-To: <1134742090.2864.65.camel@bree.local.net> References: <20051029193544.096d400e.zaitcev@redhat.com> <20051215031822.GA12020@devserv.devel.redhat.com> <20051214211008.22c1ae47.zaitcev@redhat.com> <20051215053741.GA13787@devserv.devel.redhat.com> <20051215002129.4e9863e0.zaitcev@redhat.com> <1134655233.2864.31.camel@bree.local.net> <20051216001243.446d94e3.zaitcev@redhat.com> <1134742090.2864.65.camel@bree.local.net> Message-ID: <20051217065417.GB24500@devserv.devel.redhat.com> Jeremy Katz (katzj at redhat.com) said: > > Out of curiousity, what part of the code makes these decisions: > > a) If to load USB storage drivers at all, whatever they are > > We do a kudzu probe for cd, hd or floppy devices on the usb bus -- which > basically looks for devices of usbclass 8. ... which never returns a device. We check for *SCSI* after loading the USB modules. Bill From notting at redhat.com Sat Dec 17 07:08:56 2005 From: notting at redhat.com (Bill Nottingham) Date: Sat, 17 Dec 2005 02:08:56 -0500 Subject: bittorrent in core? what frontend? In-Reply-To: <1134721846.28842.166.camel@greebo> References: <1134662961.28842.128.camel@greebo> <20051215202126.GA4210@devserv.devel.redhat.com> <1134721846.28842.166.camel@greebo> Message-ID: <20051217070856.GD24500@devserv.devel.redhat.com> Alexander Larsson (alexl at redhat.com) said: > On Thu, 2005-12-15 at 15:21 -0500, Bill Nottingham wrote: > > Alexander Larsson (alexl at redhat.com) said: > > > > I don't use bittorrent all that much. What do people think about these > > > two frontends? Are there other interesting ones? > > > > I kept meaning to package gnome-bt for Extras, and kept forgetting. > > So that would be my preference. :) > > One issue with gnome-bt is that it depends on the bittorrent package, > and the bittorrent package already includes the default gui app, so > unless you do some creative packaging you would get two bittorrent UIs > with gnome-bt as the default. True. It can be packaged around, or just ignored as a problem. It was just that it seemed to me that having gnome-bt as something that would pop up after hitting a torrent file in nautilus, firefox, etc. would be a better solution than the standalone client. Bill From zaitcev at redhat.com Sat Dec 17 07:18:39 2005 From: zaitcev at redhat.com (Pete Zaitcev) Date: Fri, 16 Dec 2005 23:18:39 -0800 Subject: libusual interface [was Re: libusual and ub] In-Reply-To: <20051217065304.GA24500@devserv.devel.redhat.com> References: <20051029193544.096d400e.zaitcev@redhat.com> <20051215031822.GA12020@devserv.devel.redhat.com> <20051214211008.22c1ae47.zaitcev@redhat.com> <20051215053741.GA13787@devserv.devel.redhat.com> <20051215002129.4e9863e0.zaitcev@redhat.com> <1134655233.2864.31.camel@bree.local.net> <20051216001243.446d94e3.zaitcev@redhat.com> <20051217065304.GA24500@devserv.devel.redhat.com> Message-ID: <20051216231839.7c4bc38a.zaitcev@redhat.com> On Sat, 17 Dec 2005 01:53:04 -0500, Bill Nottingham wrote: > I still think we should just use module aliases and either > don't auto-bind, or separate the aliases by which driver is > best. I tried that, and it would be feasible for installer, but the problem is, aliases do not work with hotplug anymore in Rusty's module-init-tools. They used to work with Keith's modutils. The reason is that Rusty's modprobe only expands aliases once (he did not want to implement loop detection). But modern kernels use a wildcard string to identify a module. This string is matched with the use of an alias mechanism, so a second match won't happen. http://www.livejournal.com/users/zaitcev/34396.html http://www.livejournal.com/users/zaitcev/34596.html -- Pete From notting at redhat.com Sat Dec 17 07:21:50 2005 From: notting at redhat.com (Bill Nottingham) Date: Sat, 17 Dec 2005 02:21:50 -0500 Subject: libusual interface [was Re: libusual and ub] In-Reply-To: <20051216231839.7c4bc38a.zaitcev@redhat.com> References: <20051029193544.096d400e.zaitcev@redhat.com> <20051215031822.GA12020@devserv.devel.redhat.com> <20051214211008.22c1ae47.zaitcev@redhat.com> <20051215053741.GA13787@devserv.devel.redhat.com> <20051215002129.4e9863e0.zaitcev@redhat.com> <1134655233.2864.31.camel@bree.local.net> <20051216001243.446d94e3.zaitcev@redhat.com> <20051217065304.GA24500@devserv.devel.redhat.com> <20051216231839.7c4bc38a.zaitcev@redhat.com> Message-ID: <20051217072150.GG24500@devserv.devel.redhat.com> Pete Zaitcev (zaitcev at redhat.com) said: > On Sat, 17 Dec 2005 01:53:04 -0500, Bill Nottingham wrote: > > > I still think we should just use module aliases and either > > don't auto-bind, or separate the aliases by which driver is > > best. > > I tried that, and it would be feasible for installer, but the problem is, > aliases do not work with hotplug anymore in Rusty's module-init-tools. > They used to work with Keith's modutils. The reason is that Rusty's > modprobe only expands aliases once (he did not want to implement > loop detection). But modern kernels use a wildcard string to identify > a module. This string is matched with the use of an alias mechanism, > so a second match won't happen. > > http://www.livejournal.com/users/zaitcev/34396.html > http://www.livejournal.com/users/zaitcev/34596.html I mean separate the aliases *into the base drivers themselves* - not using libusual at all. i.e., a given usb id only matches one of usb-storage or ub. Bill From mpeters at mac.com Sat Dec 17 08:53:22 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 17 Dec 2005 00:53:22 -0800 Subject: bittorrent in core? what frontend? In-Reply-To: <43A36275.40609@redhat.com> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A36275.40609@redhat.com> Message-ID: <1134809603.3032.28.camel@locolhost.localdomain> On Fri, 2005-12-16 at 19:57 -0500, Warren Togami wrote: > > The biggest problem with this entire idea is that it wont work for users > by default, because our default security configuration will block > incoming connections, and more users these days are behind NAT. Users behind NAT isn't a Fedora problem. They need to port forward the BT ports - but that can go on something like fedorafaq.org (or whatever it is). Firewall is a problem. A nice gui like firestarter (not necessarily firestarter, but something like it) for configuring the Fedora Firewall would be nice - with common app/port selections so users don't necessarily have to care what port ranges are used for what (unless they want to meddle with the defaults) until I decided to go with Linksys for my router, firestarter is what I used for NAT - it has a really nice interface for controlling what ports are allowed in etc. From zaitcev at redhat.com Sat Dec 17 09:33:13 2005 From: zaitcev at redhat.com (Pete Zaitcev) Date: Sat, 17 Dec 2005 01:33:13 -0800 Subject: libusual interface [was Re: libusual and ub] In-Reply-To: <20051217072150.GG24500@devserv.devel.redhat.com> References: <20051029193544.096d400e.zaitcev@redhat.com> <20051215031822.GA12020@devserv.devel.redhat.com> <20051214211008.22c1ae47.zaitcev@redhat.com> <20051215053741.GA13787@devserv.devel.redhat.com> <20051215002129.4e9863e0.zaitcev@redhat.com> <1134655233.2864.31.camel@bree.local.net> <20051216001243.446d94e3.zaitcev@redhat.com> <20051217065304.GA24500@devserv.devel.redhat.com> <20051216231839.7c4bc38a.zaitcev@redhat.com> <20051217072150.GG24500@devserv.devel.redhat.com> Message-ID: <20051217013313.3da8bfa2.zaitcev@redhat.com> On Sat, 17 Dec 2005 02:21:50 -0500, Bill Nottingham wrote: > I mean separate the aliases *into the base drivers themselves* - not > using libusual at all. i.e., a given usb id only matches one of > usb-storage or ub. Nothing new in this approach either. This is how ub worked way before libusual, and before Adrian Bunk broke it. The problem is, users require a capability to switch between drivers. And we cannot predict which one they want to use for any given device. This (old scheme) was similar to the situation with eepro100/e100, uhci/usb-uhci and other pairs. However, users weren't content with just loading drivers, they wanted hotplug to work, and so I did exactly that, "a given usb id only matches one of usb-storage or ub." That patch worked like this: diff -urp -X dontdiff linux-2.6.12/drivers/usb/storage/usb.c linux-2.6.12-lem/drivers/usb/storage/usb.c --- linux-2.6.12/drivers/usb/storage/usb.c 2005-06-17 12:48:29.000000000 -0700 +++ linux-2.6.12-lem/drivers/usb/storage/usb.c 2005-07-25 22:12:53.000000000 -0700 @@ -150,7 +150,9 @@ static struct usb_device_id storage_usb_ { USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_QIC, US_PR_BULK) }, { USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_UFI, US_PR_BULK) }, { USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_8070, US_PR_BULK) }, +#if !defined(CONFIG_BLK_DEV_UB) && !defined(CONFIG_BLK_DEV_UB_MODULE) { USB_INTERFACE_INFO(USB_CLASS_MASS_STORAGE, US_SC_SCSI, US_PR_BULK) }, +#endif /* Terminating entry */ { } @@ -224,8 +226,10 @@ static struct us_unusual_dev us_unusual_ .useTransport = US_PR_BULK}, { .useProtocol = US_SC_8070, .useTransport = US_PR_BULK}, +#if !defined(CONFIG_BLK_DEV_UB) && !defined(CONFIG_BLK_DEV_UB_MODULE) { .useProtocol = US_SC_SCSI, .useTransport = US_PR_BULK}, +#endif /* Terminating entry */ { NULL } The libusual is a result of trying (possibly) everything else. But by all means, keep throwing ideas. -- Pete From seanlkml at sympatico.ca Sat Dec 17 09:45:57 2005 From: seanlkml at sympatico.ca (Sean) Date: Sat, 17 Dec 2005 04:45:57 -0500 (EST) Subject: bittorrent in core? what frontend? In-Reply-To: <1134809603.3032.28.camel@locolhost.localdomain> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> Message-ID: On Sat, December 17, 2005 3:53 am, Michael A. Peters said: > Users behind NAT isn't a Fedora problem. They need to port forward the > BT ports - but that can go on something like fedorafaq.org (or whatever > it is). Well Fedora could help the situation by making sure its default bt client supports UPnP so that a compliant nat router (like most linksys) will automatically be configured without the user needing to deal with it at all. > Firewall is a problem. A nice gui like firestarter (not necessarily > firestarter, but something like it) for configuring the Fedora Firewall > would be nice - with common app/port selections so users don't > necessarily have to care what port ranges are used for what (unless they > want to meddle with the defaults) > > until I decided to go with Linksys for my router, firestarter is what I > used for NAT - it has a really nice interface for controlling what ports > are allowed in etc. It would be nice if the user just had to answer a simple question like "Would you like to open the ports needed for BT in your firewall configuration?". The same problem exists when trying to configure many other network apps too. It would be great to have a general framework for apps to request open ports from the firewall and have the user just get a popup so that she can agree or cancel. Perhaps this could all be done over dbus? Does something like this already exist? Sean From dragoran at feuerpokemon.de Sat Dec 17 10:19:50 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Sat, 17 Dec 2005 11:19:50 +0100 Subject: gnome 2.12 for fc4? Message-ID: <43A3E646.4070100@feuerpokemon.de> kde 3.5 was released as an update for fc4. but what about gnome 2.12? fc5 will use gnome 2.14 while fc4 still uses gnome 2.10. so any reasons for not shipping gnome 2.12? (I know that it will require a new gtk and cairo) From rodd at clarkson.id.au Sat Dec 17 11:20:55 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Sat, 17 Dec 2005 22:20:55 +1100 Subject: rawhide report: 20051216 changes In-Reply-To: <1134776133.21009.12.camel@bree.local.net> References: <200512160912.jBG9CV5E009998@porkchop.devel.redhat.com> <1134774429.3099.5.camel@localhost.localdomain> <1134776133.21009.12.camel@bree.local.net> Message-ID: <1134818455.9035.2.camel@localhost.localdomain> On Fri, 2005-12-16 at 18:35 -0500, Jeremy Katz wrote: > On Sat, 2005-12-17 at 10:07 +1100, Rodd Clarkson wrote: > > > kernel-2.6.14-1.1767_FC5 > > > ------------------------ > > > * Thu Dec 15 2005 Dave Jones > > > - 2.6.15-rc5-git5 > > > > > > * Wed Dec 14 2005 Dave Jones > > > - 2.6.15-rc5-git4 > > > - Try 'optimise for size' again. > > > - Silence noisy CD drives that spew msgs when probed whilst empty. > > > > > > * Tue Dec 13 2005 Dave Jones > > > - 2.6.15-rc5-git3 > > > - Use MMIO instead of PIO for 8139too > > > > FC5 seems keen to get me to run the smp kernel (I'm on a uniprocessor > > machine without hyperthreading). I've noticed with this update (since > > the smp kernel runs - the one that came with the original install > > didn't) that the smp kernel seems to be noticeably slower than the > > non-smp kernel. > > Do you have a processor which supports NX (see /proc/cpuinfo). If so, > we were defaulting to installing kernel-smp for test1. Unfortunately, > that has turned up some problems and so won't be the case in test2 or > later. Yes I do. Sadly, the smp kernel is significantly slower than the non-smp kernel. (or ar least for this round it is). R. -- "It's a fine line between denial and faith. It's much better on my side" From mpeters at mac.com Sat Dec 17 12:22:34 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 17 Dec 2005 04:22:34 -0800 Subject: bittorrent in core? what frontend? In-Reply-To: <39507.10.10.10.28.1134812757.squirrel@linux1> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> Message-ID: <1134822155.10233.6.camel@locolhost.localdomain> On Sat, 2005-12-17 at 04:45 -0500, Sean wrote: > On Sat, December 17, 2005 3:53 am, Michael A. Peters said: > > > Users behind NAT isn't a Fedora problem. They need to port forward the > > BT ports - but that can go on something like fedorafaq.org (or whatever > > it is). > > Well Fedora could help the situation by making sure its default bt client > supports UPnP so that a compliant nat router (like most linksys) will > automatically be configured without the user needing to deal with it at > all. I would NOT want that. I've got that turned off on my Linksys - I don't want any ports at all open for forwarding that I haven't specifically opened for forwarding. Last thing I want is someone at my house running some program that opens up port forwarding on my router. > > > Firewall is a problem. A nice gui like firestarter (not necessarily > > firestarter, but something like it) for configuring the Fedora Firewall > > would be nice - with common app/port selections so users don't > > necessarily have to care what port ranges are used for what (unless they > > want to meddle with the defaults) > > > > until I decided to go with Linksys for my router, firestarter is what I > > used for NAT - it has a really nice interface for controlling what ports > > are allowed in etc. > > It would be nice if the user just had to answer a simple question like > "Would you like to open the ports needed for BT in your firewall > configuration?". That has to be done as root, so it has to either be in Anaconda - or in a system-config tool. I personally vote for the latter, I think Anaconda is too complicated as it is. OS X (at least 10.1 - haven't installed anything later) has a sweet and simple installer. But anyway, that's just my opinion. Linus Torvalds will probably tear me a new one for wanting an installer targeted at dumb users ;) > > The same problem exists when trying to configure many other network apps > too. It would be great to have a general framework for apps to request > open ports from the firewall and have the user just get a popup so that > she can agree or cancel. Perhaps this could all be done over dbus? Does > something like this already exist? The problem with that is that root is required. I know some Windows firewalls do that - but only if you are running as admin. From seanlkml at sympatico.ca Sat Dec 17 12:41:13 2005 From: seanlkml at sympatico.ca (Sean) Date: Sat, 17 Dec 2005 07:41:13 -0500 (EST) Subject: bittorrent in core? what frontend? In-Reply-To: <1134822155.10233.6.camel@locolhost.localdomain> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> <1134822155.10233.6.camel@locolhost.localdomain> Message-ID: On Sat, December 17, 2005 7:22 am, Michael A. Peters said: > I would NOT want that. > I've got that turned off on my Linksys - I don't want any ports at all > open for forwarding that I haven't specifically opened for forwarding. > > Last thing I want is someone at my house running some program that opens > up port forwarding on my router. Well of course that's your decision to make, but we shouldn't force that decision on everyone. > That has to be done as root, so it has to either be in Anaconda - or in > a system-config tool. I personally vote for the latter, I think Anaconda > is too complicated as it is. OS X (at least 10.1 - haven't installed > anything later) has a sweet and simple installer. But anyway, that's > just my opinion. Linus Torvalds will probably tear me a new one for > wanting an installer targeted at dumb users ;) Well it can be handed off to a "root" process via dbus which imposes all the necessary security. We don't want to make this an install time option, especially for peer services like BT. You don't want a static firewall rule for a process that is only running occasionally. No, what you want is an appropriate firewall rule set only for the time that BT is actually running. Anything else is a security risk in itself. > The problem with that is that root is required. > I know some Windows firewalls do that - but only if you are running as > admin. This is a pretty easily solved techinical hurdle. A user/application combo that has been given permission to open ports could pass the request off to a thread/process with enough permission to handle the task without a problem. dbus seems like a natural fit for this. I would argue that something along this line is the only way to avoid the security risk of a static firewall rule for an application that only runs intermittently. Sean From nman64 at n-man.com Sat Dec 17 13:12:11 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Sat, 17 Dec 2005 07:12:11 -0600 Subject: freenode Message-ID: <43A40EAB.7000605@n-man.com> Over the last 20 hours, freenode has been trying to deal with a massive botnet attack. Over the course of that time, they removed the irc.freenode.net server to chat.freenode.net. Service has now been restored to irc.freenode.net, but freenode is considering a permanent transition to chat.freenode.net. In order to prepare for whatever changes freenode may make, I have adjusted references to irc.freenode.net on the wiki to point at the freenode website (http://freenode.net/) instead. For more information, or if you have trouble connecting to freenode, please see the news on their website at http://freenode.net/news.shtml I would encourage anyone who maintains websites or documentation to update their information in a similar manner. While we can expect irc.freeenode.net to remain operational for a long time to come, pointing to freenode's website rather than a server directly avoids dependency upon that server, and users will likely experience better service by visiting freenode's site and selecting a server that is geographically close to their location. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ -- Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -------------- 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 Sat Dec 17 15:40:27 2005 From: buildsys at redhat.com (Build System) Date: Sat, 17 Dec 2005 10:40:27 -0500 Subject: rawhide report: 20051217 changes Message-ID: <200512171540.jBHFeR3C001817@porkchop.devel.redhat.com> Removed package xscreensaver Updated Packages: GFS-6.1.4-0.FC5.1 ----------------- * Fri Dec 16 2005 Chris Feist - Rebuilt w/ new upstream sources * Fri Dec 09 2005 Jesse Keating - rebuilt * Tue May 17 2005 Chris Feist - Synced to upstream sources. aspell-nl-50:0.50-8 ------------------- * Fri Dec 16 2005 Ivana Varekova 50:0.50-8 - add nederlands alias (bug 175863) checkpolicy-1.28-2 ------------------ * Fri Dec 16 2005 Dan Walsh 1.28-2 - Rebuild to get latest libsepol cman-1.0.4-0.FC5.1 ------------------ * Fri Dec 16 2005 Chris Feist - Rebuilt w/ new upstream sources * Fri Dec 09 2005 Jesse Keating - rebuilt dtdparser-0:1.21-2jpp_2fc ------------------------- * Fri Dec 16 2005 Jesse Keating - 0:1.21-2jpp_2fc - rebuilt for new gcj * Tue Nov 08 2005 Vadim Nasardinov - 0:1.21-2jpp_1fc - Converted from ISO-8859-1 to UTF-8 eclipse-1:3.1.1-1jpp_10fc ------------------------- * Tue Dec 13 2005 Andrew Overholt 3.1.1-1jpp_10fc - Add patch for offline javadoc building/linking. * Mon Dec 12 2005 Andrew Overholt 3.1.1-1jpp_10fc - Use ecj from 3.1.1 (rh#175380). - Remove ecj options patch as it is in ecj from 3.1.1. - New version of launcher patch (rh#175454) - ifoox. * Sun Dec 11 2005 Andrew Overholt 3.1.1-1jpp_10fc - Build with gcc 4.1. eclipse-bugzilla-1:0.1.1_fc-6 ----------------------------- * Fri Dec 16 2005 Andrew Overholt 0.1.1_fc-6 - Build against gcc 4.1. eclipse-cdt-1:3.0.1-1jpp_2fc ---------------------------- * Fri Dec 16 2005 Andrew Overholt 3.0.1-1jpp_2fc - Build against gcc 4.1. eclipse-changelog-1:2.0.1_fc-23 ------------------------------- * Fri Dec 16 2005 Andrew Overholt 2.0.1_fc-23 - Build against gcc 4.1. eclipse-pydev-1:0.9.3_fc-13 --------------------------- * Fri Dec 16 2005 Andrew Overholt 0.9.3_fc-13 - Build against gcc 4.1. fence-1.32.10-0.FC5.1 --------------------- * Fri Dec 16 2005 Chris Feist - Rebuilt w/ new upstream sources. * Fri Dec 09 2005 Jesse Keating - rebuilt firefox-1.5-3 ------------- * Fri Dec 16 2005 Christopher Aillon - 1.5-3 - Once again, disable ppc64 because of a new issue. See https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175944 * Thu Dec 15 2005 Christopher Aillon - 1.5-2 - Use the system NSS libraries - Build on ppc64 gcc-4.1.0-0.9 ------------- * Wed Dec 14 2005 Jakub Jelinek 4.1.0-0.9 - fix OpenMP lastprivate handling for global vars (Aldy Hernandez) - fix gnu.xml.dom.DomNode's detach method (Caolan McNamara, PR classpath/25426) - fix up the #175569 fix (Tom Tromey, #175833) - fix strength reduction miscompilation of libgnomecanvas (#175669, PR rtl-optimization/24899) - create libgcj-*.jar with - at E options and feed a sorted list to it rather than relying on filesystem sorting * Tue Dec 13 2005 Jakub Jelinek 4.1.0-0.8 - update from gcc-4_1-branch (-r108414:108539) - PRs classpath/25389, fortran/23815, fortran/25078, target/25254 - fix Java ICE on initialized static final var used in case (Andrew Haley, #175569) - fix crash in _Unwind_IteratePhdrCallback (Andrew Haley) - don't Require alsa-lib-devel, just BuildRequire it (#175627) - use .gnu.linkonce.d.rel.ro.* sections for objects that are constant after relocation processing * Mon Dec 12 2005 Jakub Jelinek 4.1.0-0.7 - update from gcc-4_1-branch (-r108157:108414) - PRs c++/19317, c++/19397, c++/19762, c++/19764, c++/25010, c++/25300, c++/25337, debug/24908, fortran/25292, libfortran/25116, libgcj/25265, target/17828, target/19005, target/23424, target/25212, target/25258, target/25311, testsuite/20772, testsuite/24478, testsuite/25167, tree-optimization/25248 - update from gomp-20050608-branch (up to -r108424) - add BuildReq for alsa-lib-devel and configure with --disable-dssi - sort files in libgcj-*.jar and touch them to latest ChangeLog timestamp, so that libgcj-*.jar is identical across multilib arches - don't use pushw instruction on i?86, as that leads to ICEs in def_cfa_1, because negative CFA offsets not multiple of 4 aren't representable in the unwind and debug info (PR debug/25023, PR target/25293) - fix ICEs with x86_64 -mlarge-data-threshold=N and STRING_CSTs (Jan Hubicka, PR target/24188) - fix Java ICE with input_filename being unset (Alexandre Oliva, #174912) - don't accept invalid int x,; in C++ (Petr Machata, PR c++/24907) - fix Java ICE in do_resolve_class (Andrew Haley, PR java/25366, PR java/25368) - make sure g*.dg/compat/struct-layout-1.exp generated tests don't use arrays with entries aligned more than their size (PR c++/25331) - don't use -liberty in g++.dg/compat/struct-layout-1.exp tests gnbd-1.0.2-0.2 -------------- * Fri Dec 16 2005 Chris Feist - Rebuilt w/ new upstream sources * Fri Dec 09 2005 Jesse Keating - rebuilt * Tue May 17 2005 Chris Feist - Require cman-kernel-modules. gnome-applets-1:2.13.1-2 ------------------------ * Fri Dec 16 2005 Matthias Clasen 2.13.1-2 - Rebuild against new libgtop gnome-system-monitor-2.13.3-2 ----------------------------- * Fri Dec 16 2005 Matthias Clasen 2.13.3-2 - Rebuild against the new libgtop gulm-1.0.5-0.FC5.1 ------------------ * Fri Dec 16 2005 Chris Feist - Rebuilt w/ new upstream sources kdbg-1:2.0.2-1 -------------- * Fri Dec 16 2005 Than Ngo 1:2.0.2-1 - update to 2.0.2 kdelibs-6:3.5.0-2 ----------------- * Tue Dec 13 2005 Than Ngo 6:3.5.0-2 - apply patch to fix konqueror for working with new openssl #174541 kernel-2.6.14-1.1770_FC5 ------------------------ * Fri Dec 16 2005 David Woodhouse - Update to fixed Cell pause_zero code * Fri Dec 16 2005 Dave Jones - 2.6.15-rc5-git6 * Fri Dec 16 2005 Dave Jones - If we oops, pause a while before doing anything so that people get a chance to grab the debug info. libFS-1.0.0-1 ------------- * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated libFS to version 1.0.0 from X11R7 RC4 libICE-1.0.0-1 -------------- * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated libICE to version 1.0.0 from X11R7 RC4 libSM-1.0.0-1 ------------- * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated libSM to version 1.0.0 from X11R7 RC4 libX11-1.0.0-1 -------------- * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated libX11 to version 1.0.0 from X11R7 RC4 * Tue Dec 13 2005 Mike A. Harris 0.99.4-1 - Updated libX11 to version 0.99.4 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Fri Dec 09 2005 Jesse Keating - rebuilt libXScrnSaver-1.0.0-1 --------------------- * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated libXScrnSaver to version 1.0.0 from X11R7 RC4 libXTrap-1.0.0-1 ---------------- * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated libXTrap to version 1.0.0 from X11R7 RC4 libXau-1.0.0-1 -------------- * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated libXau to version 1.0.0 from X11R7 RC4 libXaw-1.0.0-1 -------------- * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated libXaw to version 1.0.0 from X11R7 RC4 libXcomposite-0.2.2.2-1 ----------------------- * Fri Dec 16 2005 Mike A. Harris 0.2.2.2-1 - Updated libXcomposite to version 0.2.2.2 from X11R7 RC4 libXcursor-1.1.5.2-1 -------------------- * Fri Dec 16 2005 Mike A. Harris 1.1.5.2-1 - Updated libXcursor to version 1.1.5.2 from X11R7 RC4 libXdamage-1.0.2.2-1 -------------------- * Fri Dec 16 2005 Mike A. Harris 1.0.2.2-1 - Updated libXdamage to version 1.0.2.2 from X11R7 RC4 libXdmcp-1.0.0-1 ---------------- * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated libXdmcp to version 1.0.0 from X11R7 RC4 libXevie-1.0.0-1 ---------------- * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated libXevie to version 1.0.0 from X11R7 RC4 libXext-1.0.0-1 --------------- * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated libXext to version 1.0.0 from X11R7 RC4 libXfixes-3.0.1.2-1 ------------------- * Fri Dec 16 2005 Mike A. Harris 3.0.1.2-1 - Updated libXfixes to version 3.0.1.2 from X11R7 RC4 libXfont-1.0.0-1 ---------------- * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated libXfont to version 1.0.0 from X11R7 RC4 libXfontcache-1.0.0-1 --------------------- * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated libXfontcache to version 1.0.0 from X11R7 RC4 libXft-2.1.8.2-1 ---------------- * Fri Dec 16 2005 Mike A. Harris 2.1.8.2-1 - Updated libXft to version 2.1.8.2 from X11R7 RC4 libXi-1.0.0-1 ------------- * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated libXi to version 1.0.0 from X11R7 RC4 libXinerama-1.0.0-1 ------------------- * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated libXinerama to version 1.0.0 from X11R7 RC4 libXmu-1.0.0-1 -------------- * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated libXmu to version 1.0.0 from X11R7 RC4 libXp-1.0.0-1 ------------- * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated libXp to version 1.0.0 from X11R7 RC4 * Tue Dec 13 2005 Mike A. Harris 0.99.2-1 - Updated libXp to version 0.99.2 from X11R7 RC3 - Added "Requires(pre): xorg-x11-filesystem >= 0.99.2-3", to ensure that /usr/lib/X11 and /usr/include/X11 pre-exist. - Removed 'x' suffix from manpage directories to match RC3 upstream. * Fri Dec 09 2005 Jesse Keating - rebuilt libXpm-3.5.4.2-1 ---------------- * Fri Dec 16 2005 Mike A. Harris 3.5.4.2-1 - Updated libXpm to version 3.5.4.2 from X11R7 RC4 libXrandr-1.1.0.2-1 ------------------- * Fri Dec 16 2005 Mike A. Harris 1.1.0.2-1 - Updated libXrandr to version 1.1.0.2 from X11R7 RC4 libXrender-0.9.0.2-1 -------------------- * Fri Dec 16 2005 Mike A. Harris 0.9.0.2-1 - Updated libXrender to version 0.9.0.2 from X11R7 RC4 libXres-1.0.0-1 --------------- * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated libXres to version 1.0.0 from X11R7 RC4 libXt-1.0.0-1 ------------- * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated libXt to version 1.0.0 from X11R7 RC4 - Added makestrs and it's manpage to the devel subpackage. libXtst-1.0.0-1 --------------- * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated libXtst to version 1.0.0 from X11R7 RC4 libXv-1.0.0-1 ------------- * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated libXv to version 1.0.0 from X11R7 RC4 libXvMC-1.0.0-1 --------------- * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated libXvMC to version 1.0.0 from X11R7 RC4 libXxf86dga-1.0.0-1 ------------------- * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated libXxf86dga to version 1.0.0 from X11R7 RC4 libXxf86misc-1.0.0-1 -------------------- * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated libXxf86misc to version 1.0.0 from X11R7 RC4 libXxf86vm-1.0.0-1 ------------------ * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated libXxf86vm to version 1.0.0 from X11R7 RC4 libdmx-1.0.0-1 -------------- * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated libdmx to version 1.0.0 from X11R7 RC4 libfontenc-1.0.0-1 ------------------ * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated libfontenc to version 1.0.0 from X11R7 RC4 - Added libfontenc-1.0.0-get-fontdir-from-pkgconfig.patch which now replaces libfontenc-0.99.2-use-datadir-for-encodings.patch by using pkgconfig to query fontutil.pc for fontdir. - Added "BuildRequires: font-utils >= 1.0.0" to find fontutil.pc - Removed libfontenc-0.99.2-use-datadir-for-encodings.patch libgconf-java-2.12.1-1.2 ------------------------ * Fri Dec 16 2005 Jesse Keating - 2.12.1-1.2 - rebuilt * Wed Oct 26 2005 Igor Foox - 2.12.1-1 - Updated to released 2.12.1 sources from upstream. - Excluded s390x. * Wed Oct 05 2005 Igor Foox - 2.12.0-2 - Imported released 2.12.0 source from upstream. - Changed optional installation prefix to /opt/frysk from /opt. - Added dependency for libgtk-java. liblbxutil-1.0.0-1 ------------------ * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated liblbxutil to version 1.0.0 from X11R7 RC4 liboldX-1.0.0-1 --------------- * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated liboldX to version 1.0.0 from X11R7 RC4 libsepol-1.11.1-1 ----------------- * Fri Dec 16 2005 Dan Walsh 1.11.1-1 - Upgrade to latest from NSA * Fixed mls_range_cpy bug. * Fri Dec 09 2005 Jesse Keating - rebuilt libxkbfile-1.0.0-1 ------------------ * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated libxkbfile to version 1.0.0 from X11R7 RC4 libxkbui-1.0.0-1 ---------------- * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated libxkbui to version 1.0.0 from X11R7 RC4 logwatch-7.1-4.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt magma-plugins-1.0.5-0.FC5.1 --------------------------- * Fri Dec 16 2005 Chris Feist - Rebuilt w/ new upstream sources * Fri Dec 09 2005 Jesse Keating - rebuilt mailcap-2.1.19-1.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt man-pages-cs-0.16-5.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt man-pages-da-0.1.1-12.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt man-pages-de-0.4-10.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt man-pages-es-1.28-10.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt man-pages-fr-0.9.7-11.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt man-pages-it-0.3.0-16.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt man-pages-ja-20051115-1.1 ------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt man-pages-ko-1:1.48-15.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt man-pages-pl-0.23-7.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt mcelog-1:0.4-1.11.1 ------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj net-snmp-5.2.2-4 ---------------- * Fri Dec 16 2005 Radek Vokal - 5.2.2-4 - check for header files in configure - patch for SNMPv3 traps / session user creation (net-snmp bz#1374087) * Fri Dec 09 2005 Radek Vokal - 5.2.2-3 - fix ipaddr return type on 64bit machines * Wed Dec 07 2005 Radek Vokal - 5.2.2-2 - fix read problem on stream sockets (net-snmp bz#1337534) objectweb-deploysched-0:0.2-1jpp_2fc ------------------------------------ pam-0.99.2.1-2 -------------- * Fri Dec 16 2005 Tomas Mraz 0.99.2.1-2 - fix dangling symlinks in -devel (#175929) - link libaudit only where necessary - actually compile in audit support perl-Devel-Symdump-2.03-20.1 ---------------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj perl-Digest-HMAC-1.01-14.1 -------------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj perl-Frontier-RPC-0.06-39.1 --------------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj perl-HTML-Tagset-3.04-2.1 ------------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj * Wed Mar 30 2005 Warren Togami - remove brp-compress perl-IO-String-1.08-1 --------------------- * Fri Dec 16 2005 Jason Vas Dias - 0:1.08-1 - 1.08 perl-IO-Zlib-1.04-4.1 --------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj perl-Inline-0.44-15.1 --------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj perl-Net-IP-1.24-2.1 -------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj perl-Net-Telnet-3.03-4.1 ------------------------ perl-Parse-RecDescent-1.94-5.1 ------------------------------ * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj perl-SGMLSpm-1.03ii-16.1 ------------------------ * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj perl-TimeDate-1:1.16-3.1 ------------------------ * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj perl-URI-1.35-2.1 ----------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj perl-XML-SAX-0.12-7.1 --------------------- perl-libwww-perl-5.803-2.1 -------------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj policycoreutils-1.29.2-2 ------------------------ python-docs-2.4.2-1.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt python-urlgrabber-2.9.6-4.1 --------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt rgmanager-1.9.44-0.FC5.1 ------------------------ * Fri Dec 16 2005 Chris Feist - Rebuilt with new upstream sources. * Fri Dec 09 2005 Jesse Keating - rebuilt ruby-1.8.4-0.4.preview2 ----------------------- * Fri Dec 16 2005 Akira TAGOH - 1.8.4-0.4.preview2 - updates to 1.8.4-preview2. - renamed the packages to ruby-* (#175765) - irb -> ruby-irb - rdoc -> ruby-rdoc - ri -> ruby-ri - added tcl-devel and tk-devel into BuildRequires. selinux-policy-2.1.6-8 ---------------------- * Fri Dec 16 2005 Dan Walsh 2.1.5-8 - Update mls file from old version * Thu Dec 15 2005 Dan Walsh 2.1.5-5 - Add sids back in - Rebuild with update checkpolicy * Thu Dec 15 2005 Dan Walsh 2.1.5-4 - Fixes to allow automount to use portmap - Fixes to start kernel in s0-s15:c0.c255 smartmontools-1:5.33-4 ---------------------- * Fri Dec 16 2005 Tomas Mraz 1:5.33-4 - mail should be sent to root not root at localhost (#174252) system-config-nfs-1.3.15-1 -------------------------- * Fri Dec 16 2005 Nils Philippsen 1.3.15 - don't apply server settings (non-)changes on Cancel - make server settings dialog actually show all text entries * Fri Dec 16 2005 Nils Philippsen 1.3.14 - translate permissions column (#175921, patch by Frank Arnold) * Fri Oct 14 2005 Nils Philippsen - don't use pam_stack (#170637) wsdl4j-0:1.5.1-1jpp_2fc ----------------------- * Fri Dec 09 2005 Jesse Keating - 0:1.5.1-1jpp_2fc - rebuilt * Tue Nov 08 2005 Vadim Nasardinov - 0:1.5.1-1jpp_1fc - Converted from ISO-8859-1 to UTF-8 xml-commons-resolver-0:1.1-1jpp_6fc.1 ------------------------------------- * Fri Dec 09 2005 Jesse Keating 0:1.1-1jpp_6fc - rebuilt xorg-x11-font-utils-1:1.0.0-1 ----------------------------- * Thu Dec 15 2005 Mike A. Harris 1:1.0.0-1 - Updated all utilities to version 1.0.0 from X11R7 RC4. - Updated font-util-1.0.0-mapdir-use-datadir-fix.patch to work with RC4. - Added font-util-1.0.0-autoconf-add-with-fontdir-option.patch to add a new variable "fontdir" to the fontutil.pc file which all of the font packages can autodetect and use instead of having to put manual fontdir overrides in every single rpm package. * Tue Dec 13 2005 Mike A. Harris 1:0.99.2-1 - Updated bdftopcf, fonttosfnt to version 0.99.3, and mkfontdir, mkfontscale, and font-util to version 0.99.2 from X11R7 RC3. - Changed manpage dir from man1x back to man1 due to another upstream change. - Added fontutil.m4 to file manifest. xorg-x11-fonts-1.0.0-1 ---------------------- * Thu Dec 15 2005 Mike A. Harris 1.0.0-1 - Updated all font packages to X11R7 RC4 versions. - Added perl hack to build section to massage all of the configure.ac files to use pkgconfig to autodetect the top level X fontdir. - Added font-alias-1.0.0-fonts-alias-fontdir-fix.patch to use pkgconfig to autodetect the top level X fontdir. - Added encodings-1.0.0-encodings-fontdir-fix.patch to use pkgconfig to autodetect the top level X fontdir. - Use new --disable-iso8859-* options instead of deleting unwanted encodings. - Added dependency on font-utils 1.0.0 * Tue Dec 13 2005 Mike A. Harris 0.99.3-1 - Updated all font packages to X11R7 RC3 versions. xorg-x11-proto-devel-0.99.4-1 ----------------------------- * Thu Dec 15 2005 Mike A. Harris 0.99.4-1 - Update all proto tarballs to the RC4 release. xorg-x11-resutils-1.0.0-1 ------------------------- * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Update all resource utils to version 1.0.0 from X11R7 RC4. - Move app-defaults files to _datadir - Change manpage dir from man1x to man1 to match RC4 default. - Added "BuildRequires: libX11-devel, libXt-devel" xorg-x11-server-utils-1.0.0-1 ----------------------------- * Mon Nov 28 2005 Mike A. Harris 1.0.0-1 - Updated all packages to version 1.0.0 from X11R7 RC4 - Changed manpage dirs from man1x to man1 to match upstream RC4 default. - Updated lbxproxy-datadir-AtomControl-fix.patch - Updated rgb-1.0.0-datadir-rgbpath-fix.patch - Removed xvidtune-0.99.1-datadir-app-defaults-fix.patch, now unneeded. xorg-x11-twm-1:1.0.0-1 ---------------------- * Fri Dec 16 2005 Mike A. Harris 1:1.0.0-1 - Updated to twm 1.0.0 from X11R7 RC4. - Change manpage dir from man1x to man1 to match RC4 default. * Tue Nov 15 2005 Mike A. Harris 1:0.99.1-4 - Added "BuildRequires: libXau-devel", as twm fails without it, but does not check for it with ./configure. Bug (fdo#5065) xorg-x11-util-macros-1.0.0-1 ---------------------------- * Thu Dec 15 2005 Mike A. Harris 1.0.0-1 - Update to util-macros-1.0.0 from the X11R7 RC4 release. xorg-x11-xauth-1:1.0.0-1 ------------------------ * Fri Dec 16 2005 Mike A. Harris 1:1.0.0-1 - Updated to xauth 1.0.0 from X11R7 RC4 - Changed manpage dir from man1x to man1 to match upstream default. xorg-x11-xfs-1:1.0.0-1 ---------------------- * Fri Dec 16 2005 Mike A. Harris 1:1.0.0-1 - Updated all tarballs to version 1.0.0 from X11R7 RC4. - Get default X font directory with font-utils package 'fontdir' pkgconfig variable. - Change manpage dir from man1x back to man1 to match upstream. xorg-x11-xfwp-1.0.0-1 --------------------- * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated all tarballs to version 1.0.0 from X11R7 RC4. - Changed manpage dir from man1x to man1 to match RC4 default. xorg-x11-xinit-1.0.0-1 ---------------------- * Fri Dec 16 2005 Mike A. Harris 1.0.0-1 - Updated to xinit 1.0.0 from X11R7 RC4. - Changed manpage dir from man1x to man1 to match upstream default. xorg-x11-xsm-1.0.0-1 -------------------- * Tue Nov 22 2005 Mike A. Harris 1.0.0-1 - Updated all apps to version 1.0.0 from X11R7 RC4. - Changed manpage dir from man1x to man1 to match upstream default. xorg-x11-xtrans-devel-1.0.0-1 ----------------------------- * Thu Dec 15 2005 Mike A. Harris 1.0.0-1 - Update to xtrans-1.0.0 from X11R7 RC4 release. yelp-2.13.2-2 ------------- * Thu Dec 15 2005 David Malcolm - 2.13.2-2 - Patched to include DocBook mimetype in desktop file, and added preun and post hooks to update-desktop-database (#175880) - Patched to ensure that Yelp recognizes that it can handle the mimetype of the documentation as reported by gnomevfs (also #175880) yum-2.5.0-4 ----------- * Fri Dec 16 2005 Paul Nasrat - 2.5.0-4 - Fix for KeyError when no location['base'] Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel = 0:2.6.14-1.1696_FC5 cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5smp cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel = 0:2.6.14-1.1696_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 gnome-python2-libgtop2 - 2.12.1-7.1.i386 requires libgtop-2.0.so.5 jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 kdeartwork - 3.5.0-1.1.i386 requires xscreensaver >= 0:4.18-14 mesa-libGL - 6.4-5.i386 requires libdrm.so.1 systemtap - 0.5-2.i386 requires libdw.so.1(ELFUTILS_0.116) Broken deps for ia64 ---------------------------------------------------------- gnome-python2-libgtop2 - 2.12.1-7.1.ia64 requires libgtop-2.0.so.5()(64bit) jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) kdeartwork - 3.5.0-1.1.ia64 requires xscreensaver >= 0:4.18-14 mesa-libGL - 6.4-5.ia64 requires libdrm.so.1()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs systemtap - 0.5-2.ia64 requires libdw.so.1(ELFUTILS_0.116)(64bit) Broken deps for ppc ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 gnome-python2-libgtop2 - 2.12.1-7.1.ppc requires libgtop-2.0.so.5 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 kdeartwork - 3.5.0-1.1.ppc requires xscreensaver >= 0:4.18-14 mesa-libGL - 6.4-5.ppc requires libdrm.so.1 systemtap - 0.5-2.ppc requires libdw.so.1(ELFUTILS_0.116) Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 gnome-python2-libgtop2 - 2.12.1-7.1.ppc64 requires libgtop-2.0.so.5()(64bit) jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) kdeartwork - 3.5.0-1.1.ppc64 requires xscreensaver >= 0:4.18-14 Broken deps for s390 ---------------------------------------------------------- gnome-python2-libgtop2 - 2.12.1-7.1.s390 requires libgtop-2.0.so.5 jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 kdeartwork - 3.5.0-1.1.s390 requires xscreensaver >= 0:4.18-14 Broken deps for s390x ---------------------------------------------------------- gnome-python2-libgtop2 - 2.12.1-7.1.s390x requires libgtop-2.0.so.5()(64bit) jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) kdeartwork - 3.5.0-1.1.s390x requires xscreensaver >= 0:4.18-14 libglade-java - 2.12.0-5.s390x requires libgcj.so.6()(64bit) libglade-java - 2.12.0-5.s390x requires libcairojava-1.0.so()(64bit) libgnome-java - 2.12.0-2.s390x requires libgcj.so.6()(64bit) libgnome-java - 2.12.0-2.s390x requires libcairojava-1.0.so()(64bit) libgtk-java - 2.8.0-7.s390x requires libgcj.so.6()(64bit) libvte-java - 0.11.11-6.3.s390x requires libcairojava-1.0.so()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 gnome-python2-libgtop2 - 2.12.1-7.1.x86_64 requires libgtop-2.0.so.5()(64bit) jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) kdeartwork - 3.5.0-1.1.x86_64 requires xscreensaver >= 0:4.18-14 mesa-libGL - 6.4-5.i386 requires libdrm.so.1 mesa-libGL - 6.4-5.x86_64 requires libdrm.so.1()(64bit) systemtap - 0.5-2.x86_64 requires libdw.so.1(ELFUTILS_0.116)(64bit) From mpeters at mac.com Sat Dec 17 15:53:13 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 17 Dec 2005 07:53:13 -0800 Subject: bittorrent in core? what frontend? In-Reply-To: <41673.10.10.10.28.1134823273.squirrel@linux1> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> <1134822155.10233.6.camel@locolhost.localdomain> <41673.10.10.10.28.1134823273.squirrel@linux1> Message-ID: <1134834793.13361.3.camel@locolhost.localdomain> On Sat, 2005-12-17 at 07:41 -0500, Sean wrote: > > Well it can be handed off to a "root" process via dbus which imposes all > the necessary security. We don't want to make this an install time > option, especially for peer services like BT. You don't want a static > firewall rule for a process that is only running occasionally. No, what > you want is an appropriate firewall rule set only for the time that BT is > actually running. Anything else is a security risk in itself. Oh I see what you are saying. When trusted application foo is being run by user in trusted group bar (or open for any user) - the firewall will open ports xxxx to yyyy should foo request they be opened - for the duration that foo is running. That would be slick. From jfrieben at freesurf.fr Sat Dec 17 16:47:45 2005 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Sat, 17 Dec 2005 17:47:45 +0100 (CET) Subject: Stack protector disables various browser plugins Message-ID: <42354.194.94.224.254.1134838065.squirrel@jose.freesurf.fr> Current versions of common browser plugins get disabled by SELinux' stack protection. These include "flash-plugin-7.0.61-1" and "jre-1.5.0_06". They become available again after booting with "enforcing=0". From dravet at hotmail.com Sat Dec 17 16:49:02 2005 From: dravet at hotmail.com (Jason Dravet) Date: Sat, 17 Dec 2005 10:49:02 -0600 Subject: problems with xorg-x11-xfs in todays rawhide Message-ID: I did a yum update --exclude=libdrm this morning and during the install I get the following message: Updating : xorg-x11-xfs ##################### [ 83/166] syntax error at -e line 1, at EOF Execution of -e aborted due to compilation errors. Just an FYI, Jason From drepper at redhat.com Sat Dec 17 16:56:25 2005 From: drepper at redhat.com (Ulrich Drepper) Date: Sat, 17 Dec 2005 08:56:25 -0800 Subject: Stack protector disables various browser plugins In-Reply-To: <42354.194.94.224.254.1134838065.squirrel@jose.freesurf.fr> References: <42354.194.94.224.254.1134838065.squirrel@jose.freesurf.fr> Message-ID: <43A44339.10709@redhat.com> Joachim Frieben wrote: > Current versions of common browser plugins get disabled by > SELinux' stack protection. These include "flash-plugin-7.0.61-1" > and "jre-1.5.0_06". They become available again after booting > with "enforcing=0". Find the DSOs implementing those and run chcon system_u:object_r:texrel_shlib_t THE-FILE for each of the files. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? From seanlkml at sympatico.ca Sat Dec 17 17:58:40 2005 From: seanlkml at sympatico.ca (Sean) Date: Sat, 17 Dec 2005 12:58:40 -0500 (EST) Subject: bittorrent in core? what frontend? In-Reply-To: <1134834793.13361.3.camel@locolhost.localdomain> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> <1134822155.10233.6.camel@locolhost.localdomain> <41673.10.10.10.28.1134823273.squirrel@linux1> <1134834793.13361.3.camel@locolhost.localdomain> Message-ID: On Sat, December 17, 2005 10:53 am, Michael A. Peters said: > Oh I see what you are saying. When trusted application foo is being run > by user in trusted group bar (or open for any user) - the firewall will > open ports xxxx to yyyy should foo request they be opened - for the > duration that foo is running. > > That would be slick. Yeah, you said more clearly than what i muddled out. Somewhere in the mix a policy could be set to force the user to agree/cancel or enter a password (perhaps just on the first invocation). If this dynamic-firewall service became common most network apps could be updated to use it. Hopefully it would make things easier for the casual user with a simple setup. Ultimately the dynamic-firewall service could even have an option to do UPnP or zeroconf too, and thus enable auto-port-forwarding for any app (if desired). Wouldn't surprise me to find out that someone is already working on something like this though. Sean From mpeters at mac.com Sat Dec 17 18:36:32 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 17 Dec 2005 10:36:32 -0800 Subject: gnome 2.12 for fc4? In-Reply-To: <43A3E646.4070100@feuerpokemon.de> References: <43A3E646.4070100@feuerpokemon.de> Message-ID: <1134844592.13361.16.camel@locolhost.localdomain> On Sat, 2005-12-17 at 11:19 +0100, dragoran wrote: > kde 3.5 was released as an update for fc4. > but what about gnome 2.12? > fc5 will use gnome 2.14 while fc4 still uses gnome 2.10. > so any reasons for not shipping gnome 2.12? (I know that it will require > a new gtk and cairo) and a new gtkhtml3 and new other stuff too. I doubt it will happen. From pbrobinson at gmail.com Sat Dec 17 18:44:35 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Sat, 17 Dec 2005 18:44:35 +0000 Subject: gnome 2.12 for fc4? In-Reply-To: <1134844592.13361.16.camel@locolhost.localdomain> References: <43A3E646.4070100@feuerpokemon.de> <1134844592.13361.16.camel@locolhost.localdomain> Message-ID: <5256d0b0512171044h1c670ce6mc7525b0483da8342@mail.gmail.com> On 12/17/05, Michael A. Peters wrote: > On Sat, 2005-12-17 at 11:19 +0100, dragoran wrote: > > kde 3.5 was released as an update for fc4. > > but what about gnome 2.12? > > fc5 will use gnome 2.14 while fc4 still uses gnome 2.10. > > so any reasons for not shipping gnome 2.12? (I know that it will require > > a new gtk and cairo) > > and a new gtkhtml3 and new other stuff too. > I doubt it will happen. Why wouldn't it considering the current rawhide already has gnome 2.13.x and evo 2.5.x (which requires the latest gtkhtml3).... see the wiki! P From jkeating at redhat.com Sat Dec 17 19:08:44 2005 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 17 Dec 2005 11:08:44 -0800 Subject: rawhide report: 20051217 changes In-Reply-To: <200512171540.jBHFeR3C001817@porkchop.devel.redhat.com> References: <200512171540.jBHFeR3C001817@porkchop.devel.redhat.com> Message-ID: <1134846524.24472.70.camel@yoda.loki.me> On Sat, 2005-12-17 at 10:40 -0500, Build System wrote: > > Removed package xscreensaver This package is going back in. I accidentally removed it and it wasn't able to be rebuilt in time to make the rawhide roll. Don't panic, it'll be there tomorrow (: -- Jesse Keating Release Engineer: Fedora From jkeating at j2solutions.net Sat Dec 17 19:12:16 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 17 Dec 2005 11:12:16 -0800 Subject: gnome 2.12 for fc4? In-Reply-To: <5256d0b0512171044h1c670ce6mc7525b0483da8342@mail.gmail.com> References: <43A3E646.4070100@feuerpokemon.de> <1134844592.13361.16.camel@locolhost.localdomain> <5256d0b0512171044h1c670ce6mc7525b0483da8342@mail.gmail.com> Message-ID: <1134846736.24472.75.camel@yoda.loki.me> On Sat, 2005-12-17 at 18:44 +0000, Peter Robinson wrote: > > Why wouldn't it considering the current rawhide already has gnome > 2.13.x and evo 2.5.x (which requires the latest gtkhtml3).... see the > wiki! Mostly because FC5 is very close now. Developer hours are being poured into making sure that FC5 is the best it could be and somewhat on time. Upgrading gnome in FC4 is a rather large chunk of work, which could probably be finished up properly just in time for FC5 to come out. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From fedora at leemhuis.info Sat Dec 17 19:14:09 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Sat, 17 Dec 2005 20:14:09 +0100 Subject: gnome 2.12 for fc4? In-Reply-To: <1134844592.13361.16.camel@locolhost.localdomain> References: <43A3E646.4070100@feuerpokemon.de> <1134844592.13361.16.camel@locolhost.localdomain> Message-ID: <1134846849.2902.27.camel@localhost.localdomain> Am Samstag, den 17.12.2005, 10:36 -0800 schrieb Michael A. Peters: > On Sat, 2005-12-17 at 11:19 +0100, dragoran wrote: > > kde 3.5 was released as an update for fc4. > > but what about gnome 2.12? > > fc5 will use gnome 2.14 while fc4 still uses gnome 2.10. > > so any reasons for not shipping gnome 2.12? (I know that it will require > > a new gtk and cairo) > > and a new gtkhtml3 and new other stuff too. > I doubt it will happen. Agreed. Especially now that FC5 is not that far away anymore. We IMHO should sync the fedora schedule with the gnome schedule in someway. Maybe the gnome people then hand out fedora-cds instead of ubuntu-cds on fairs again ;-) CU thl -- Thorsten Leemhuis From jkeating at j2solutions.net Sat Dec 17 19:15:31 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 17 Dec 2005 11:15:31 -0800 Subject: bittorrent in core? what frontend? In-Reply-To: <39507.10.10.10.28.1134812757.squirrel@linux1> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> Message-ID: <1134846931.24472.78.camel@yoda.loki.me> On Sat, 2005-12-17 at 04:45 -0500, Sean wrote: > Well Fedora could help the situation by making sure its default bt client > supports UPnP so that a compliant nat router (like most linksys) will > automatically be configured without the user needing to deal with it at > all. I would rather hope not. I like to think that Fedora systems are relatively secure by default, and running applications in default manners won't change that. Having upnp on by default can lead to randomly open ports for forwarding and that is not a good thing. Goes against the whole ideal of secure by default. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From seanlkml at sympatico.ca Sat Dec 17 19:19:15 2005 From: seanlkml at sympatico.ca (Sean) Date: Sat, 17 Dec 2005 14:19:15 -0500 (EST) Subject: bittorrent in core? what frontend? In-Reply-To: <1134846931.24472.78.camel@yoda.loki.me> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> <1134846931.24472.78.camel@yoda.loki.me> Message-ID: On Sat, December 17, 2005 2:15 pm, Jesse Keating said: > I would rather hope not. I like to think that Fedora systems are > relatively secure by default, and running applications in default > manners won't change that. Having upnp on by default can lead to > randomly open ports for forwarding and that is not a good thing. Goes > against the whole ideal of secure by default. Actually it's more about working-by-default. There is nothing insecure about providing port-forwarding access to the bit-torrent client while it is active. Especially since the forwarding is disabled when the application is turned off. For those who truly object to this, UPnP can be disabled on the router. Sean From jkeating at j2solutions.net Sat Dec 17 19:27:43 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 17 Dec 2005 11:27:43 -0800 Subject: bittorrent in core? what frontend? In-Reply-To: <35487.10.10.10.28.1134847155.squirrel@linux1> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> <1134846931.24472.78.camel@yoda.loki.me> <35487.10.10.10.28.1134847155.squirrel@linux1> Message-ID: <1134847663.24472.82.camel@yoda.loki.me> On Sat, 2005-12-17 at 14:19 -0500, Sean wrote: > Actually it's more about working-by-default. There is nothing insecure > about providing port-forwarding access to the bit-torrent client while it > is active. Especially since the forwarding is disabled when the > application is turned off. For those who truly object to this, UPnP can > be disabled on the router. The point is more that we don't want random applications poking holes in firewalls that are beyond the system. All it takes is for some exploit to be discovered within the btclient, and whammo. I'm sorry that BT is so difficult to use that you have to futz with firewalls. But I don't feel that it is Fedora's place to allow applications to poke holes in firewalls not even on the system. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From jspaleta at gmail.com Sat Dec 17 19:30:04 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 17 Dec 2005 14:30:04 -0500 Subject: bittorrent in core? what frontend? In-Reply-To: References: <1134662961.28842.128.camel@greebo> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> <1134846931.24472.78.camel@yoda.loki.me> Message-ID: <604aa7910512171130vc14bc56g4c37fc8008574ef9@mail.gmail.com> On 12/17/05, Sean wrote: > Actually it's more about working-by-default. There is nothing insecure > about providing port-forwarding access to the bit-torrent client while it > is active. Especially since the forwarding is disabled when the > application is turned off. For those who truly object to this, UPnP can > be disabled on the router. I don't think the issue is the bittorrent client specifically. The has to do with whether or not the local firewall should be trusting these kind of requests for port opening from applications generally.. without knowledge as to purpose or intent. Whose to say that the next application to need this functionality isn't doing so for malicious means. -jef From seanlkml at sympatico.ca Sat Dec 17 19:32:37 2005 From: seanlkml at sympatico.ca (Sean) Date: Sat, 17 Dec 2005 14:32:37 -0500 (EST) Subject: bittorrent in core? what frontend? In-Reply-To: <1134847663.24472.82.camel@yoda.loki.me> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> <1134846931.24472.78.camel@yoda.loki.me> <35487.10.10.10.28.1134847155.squirrel@linux1> <1134847663.24472.82.camel@yoda.loki.me> Message-ID: On Sat, December 17, 2005 2:27 pm, Jesse Keating said: > > The point is more that we don't want random applications poking holes in > firewalls that are beyond the system. All it takes is for some exploit > to be discovered within the btclient, and whammo. > > I'm sorry that BT is so difficult to use that you have to futz with > firewalls. But I don't feel that it is Fedora's place to allow > applications to poke holes in firewalls not even on the system. It's not just bit-torrent that's only the current example. If you want to imagine every possible future exploit you'd never connect any computer to the internet. The point is setting things up to work easily and with little fuss for the average user. Taking advantage of the facilities provided by their network to make life easier for them. For those people who don't like this feature they can (and should!) disable UPnP on their router because any random appliation could be using it on them otherwise. Really, this introduces very little risk and adds quite a bit of simplification for the average user and is very easy to shut off for anyone who just isn't comfortable with it. Sean From seanlkml at sympatico.ca Sat Dec 17 19:36:21 2005 From: seanlkml at sympatico.ca (Sean) Date: Sat, 17 Dec 2005 14:36:21 -0500 (EST) Subject: bittorrent in core? what frontend? In-Reply-To: <604aa7910512171130vc14bc56g4c37fc8008574ef9@mail.gmail.com> References: <1134662961.28842.128.camel@greebo> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> <1134846931.24472.78.camel@yoda.loki.me> <604aa7910512171130vc14bc56g4c37fc8008574ef9@mail.gmail.com> Message-ID: On Sat, December 17, 2005 2:30 pm, Jeff Spaleta said: > I don't think the issue is the bittorrent client specifically. The > has to do with whether or not the local firewall should be trusting > these kind of requests for port opening from applications generally.. > without knowledge as to purpose or intent. Whose to say that the next > application to need this functionality isn't doing so for malicious > means. Well we're talking about two different things here. One is the local firewall rules, lets set that aside for a moment. The other is the use of auto-port-forwarding on a nat router connecting a home network to the internet. My contention is it's not our job to decide the policy on this. We should use the facility if it is enabled on the router. For those who don't agree with this functionality they can shut it off. And really, without a corresponding change to the firewall rules on the local machine the port forwarding on the router has __0 effect__. Because any packets forwarded to the local machine will still be rejected by the firewall. Sean From jkeating at j2solutions.net Sat Dec 17 19:39:02 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 17 Dec 2005 11:39:02 -0800 Subject: bittorrent in core? what frontend? In-Reply-To: <56802.10.10.10.28.1134847957.squirrel@linux1> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> <1134846931.24472.78.camel@yoda.loki.me> <35487.10.10.10.28.1134847155.squirrel@linux1> <1134847663.24472.82.camel@yoda.loki.me> <56802.10.10.10.28.1134847957.squirrel@linux1> Message-ID: <1134848342.24472.88.camel@yoda.loki.me> On Sat, 2005-12-17 at 14:32 -0500, Sean wrote: > It's not just bit-torrent that's only the current example. If you want > to imagine every possible future exploit you'd never connect any computer > to the internet. yes and no. Those that open their own ports to be forwarded are rather insiduous. They don't rely on an established/related communication, so any data can come down that forward into the client, not just that which is expected. > The point is setting things up to work easily and with little fuss for the > average user. Taking advantage of the facilities provided by their > network to make life easier for them. For those people who don't like > this feature they can (and should!) disable UPnP on their router because > any random appliation could be using it on them otherwise. And the folks that don't understand the evils of upnp are the folks that are going to leave it open. Secure by default, let users hang themselves w/ the rope that is provided in options. > Really, this introduces very little risk and adds quite a bit of > simplification for the average user and is very easy to shut off for > anyone who just isn't comfortable with it. Every bit of little risk adds up into a platform that is risky by default, and folks have to spend effort to 'secure' it after installation. This is a path I would _not_ like to see Fedora go down. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From admin at ramshacklestudios.com Sat Dec 17 19:39:05 2005 From: admin at ramshacklestudios.com (Peter Gordon) Date: Sat, 17 Dec 2005 11:39:05 -0800 Subject: gnome 2.12 for fc4? In-Reply-To: <43A3E646.4070100@feuerpokemon.de> References: <43A3E646.4070100@feuerpokemon.de> Message-ID: <1134848345.752.7.camel@tuxhugger> On Sat, 2005-12-17 at 11:19 +0100, dragoran wrote: > kde 3.5 was released as an update for fc4. > but what about gnome 2.12? > fc5 will use gnome 2.14 while fc4 still uses gnome 2.10. > so any reasons for not shipping gnome 2.12? (I know that it will require > a new gtk and cairo) There was an article about this on FedoraNews soon after the release of GNOME 2.12: Essentially, you configure your system to use a third-party repository for all of the GNOME 2.12 stuff. Please note that is probably entirely unsupported by the Fedora dev team, and it can easily break your system if you're not very careful. I've not tried this, so I can't comment on it further. -- Peter Gordon (codergeek42) GnuPG Public Key: 0xDA3634D7 -------------- 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 seanlkml at sympatico.ca Sat Dec 17 19:47:05 2005 From: seanlkml at sympatico.ca (Sean) Date: Sat, 17 Dec 2005 14:47:05 -0500 (EST) Subject: bittorrent in core? what frontend? In-Reply-To: <1134848342.24472.88.camel@yoda.loki.me> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> <1134846931.24472.78.camel@yoda.loki.me> <35487.10.10.10.28.1134847155.squirrel@linux1> <1134847663.24472.82.camel@yoda.loki.me> <56802.10.10.10.28.1134847957.squirrel@linux1> <1134848342.24472.88.camel@yoda.loki.me> Message-ID: On Sat, December 17, 2005 2:39 pm, Jesse Keating said: > > yes and no. Those that open their own ports to be forwarded are rather > insiduous. They don't rely on an established/related communication, so > any data can come down that forward into the client, not just that which > is expected. This is no different than if the ports are opened manually though. Anyone who has to open them manually is likely to leave them open when they shut down their bit torrent client as well. So really UPnP is more secure because the ports are only forwarded while the application is active. > > And the folks that don't understand the evils of upnp are the folks that > are going to leave it open. Secure by default, let users hang > themselves w/ the rope that is provided in options. The risk seems very minimal and the reward rather large. > Every bit of little risk adds up into a platform that is risky by > default, and folks have to spend effort to 'secure' it after > installation. This is a path I would _not_ like to see Fedora go down. Well almost everything adds a bit of risk; letting a user log into the machine is risky, yet we want our computers to be usable, not just locked in a box with no power cord attached. And in this case using the UPnP facility actually can mitigate some risk as well since the ports are properly closed when not in use. On top of that it makes life easier for users. Sean From seg at haxxed.com Sat Dec 17 19:54:43 2005 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 17 Dec 2005 13:54:43 -0600 Subject: bittorrent in core? what frontend? In-Reply-To: <1134847663.24472.82.camel@yoda.loki.me> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> <1134846931.24472.78.camel@yoda.loki.me> <35487.10.10.10.28.1134847155.squirrel@linux1> <1134847663.24472.82.camel@yoda.loki.me> Message-ID: <1134849284.22444.11.camel@hamburger.booze> > I'm sorry that BT is so difficult to use that you have to futz with > firewalls. But I don't feel that it is Fedora's place to allow > applications to poke holes in firewalls not even on the system. Not this flame war again. The only way P2P can *possibly* work is if you poke holes through the firewall. If everyone were behind firewalls and couldn't poke holes, there would be no P2P. If only a few people poke holes, those nodes become solely responsible for uploading to the firewalled nodes. The firewalled nodes still can't talk to each other. And another thing, the whole point of a firewall is to keep malicious stuff out. With UPNP/NAT-PMP, port forwards can only be set up from behind the firewall. And only to the machine asking for it. If you've got malicious software and/or users behind your firewall, you've already lost the security battle. 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 kloczek at zie.pg.gda.pl Sat Dec 17 19:58:04 2005 From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=) Date: Sat, 17 Dec 2005 20:58:04 +0100 Subject: rawhide report: 20051217 changes In-Reply-To: <200512171540.jBHFeR3C001817@porkchop.devel.redhat.com> References: <200512171540.jBHFeR3C001817@porkchop.devel.redhat.com> Message-ID: <1134849484.21177.25.camel@test1.zie.pg.gda.pl> Dnia 17-12-2005, sob o godzinie 10:40 -0500, Build System napisa?(a): [..] > logwatch-7.1-4.1 > ---------------- > * Fri Dec 09 2005 Jesse Keating > - rebuilt [..] > mailcap-2.1.19-1.1 > ------------------ > * Fri Dec 09 2005 Jesse Keating > - rebuilt > > man-pages-cs-0.16-5.1 > --------------------- > * Fri Dec 09 2005 Jesse Keating > - rebuilt [..and all other man-pages-*..] Sorry but what is the sense rebuilding this noarch packages. IMO this only waste of time and energy. > perl-Devel-Symdump-2.03-20.1 > ---------------------------- > * Fri Dec 16 2005 Jesse Keating > - rebuilt for new gcj [..and all other perl modules. Specialy packed in noarch packages..] Next: how chages in libgcj affects perl modules ??? specialy noarch perl modules ? :-o This next plain waste of time and energy for supply build systems. kloczek From jspaleta at gmail.com Sat Dec 17 20:04:08 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 17 Dec 2005 15:04:08 -0500 Subject: bittorrent in core? what frontend? In-Reply-To: <1134849284.22444.11.camel@hamburger.booze> References: <1134662961.28842.128.camel@greebo> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> <1134846931.24472.78.camel@yoda.loki.me> <35487.10.10.10.28.1134847155.squirrel@linux1> <1134847663.24472.82.camel@yoda.loki.me> <1134849284.22444.11.camel@hamburger.booze> Message-ID: <604aa7910512171204s4e8caf24k91a907f03a208294@mail.gmail.com> On 12/17/05, Callum Lerwick wrote: > Not this flame war again. The only way P2P can *possibly* work is if you > poke holes through the firewall. If everyone were behind firewalls and > couldn't poke holes, there would be no P2P. If only a few people poke > holes, those nodes become solely responsible for uploading to the > firewalled nodes. The firewalled nodes still can't talk to each other. > > And another thing, the whole point of a firewall is to keep malicious > stuff out. With UPNP/NAT-PMP, port forwards can only be set up from > behind the firewall. And only to the machine asking for it. If you've > got malicious software and/or users behind your firewall, you've already > lost the security battle. Get over it. There's a big difference between users delibrately deciding to poke holes in their firewall, and having the operating system let any application automatically poke holes without authentication to allow the action. I'd be perfectly fine with a mechanism that applications could use which first request permissions to open ports from the user and notified the user as to which application was making the request, before ports were dynamically opened. -jef From seg at haxxed.com Sat Dec 17 20:12:39 2005 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 17 Dec 2005 14:12:39 -0600 Subject: bittorrent in core? what frontend? In-Reply-To: <41673.10.10.10.28.1134823273.squirrel@linux1> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> <1134822155.10233.6.camel@locolhost.localdomain> <41673.10.10.10.28.1134823273.squirrel@linux1> Message-ID: <1134850359.22444.26.camel@hamburger.booze> > Well it can be handed off to a "root" process via dbus which imposes all > the necessary security. We don't want to make this an install time > option, especially for peer services like BT. You don't want a static > firewall rule for a process that is only running occasionally. No, what > you want is an appropriate firewall rule set only for the time that BT is > actually running. Anything else is a security risk in itself. Actually, when you're talking about processes on the local machine, firewall rules are a totally hackish way of going about this. What you want to do, is have some kind of local ACL that says what processes and users can bind to what ports. This would solve a whole mess of security problems. (Look around, a great many server daemons have to be started as root, for the mere fact they want to bind to ports <1024.) Instead of firewalling, make the kernel disallow processes from even binding listen ports at all in the first place. I know back when I was playing with grsecurity years ago, it had a feature like this. It had group-based access control, you could set up a certain group and say "This group can not bind listen ports" and even "This group can't make outgoing connections" too. Or you could turn it around and say "Only this group can bind to ports" etc. It had some weird side effects though. IIRC various things wanted to bind to loopback... Can selinux do this? If not, it should. -------------- 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 mailinglists at erwinrol.com Sat Dec 17 20:09:08 2005 From: mailinglists at erwinrol.com (Erwin Rol) Date: Sat, 17 Dec 2005 21:09:08 +0100 Subject: rawhide report: 20051217 changes In-Reply-To: <1134849484.21177.25.camel@test1.zie.pg.gda.pl> References: <200512171540.jBHFeR3C001817@porkchop.devel.redhat.com> <1134849484.21177.25.camel@test1.zie.pg.gda.pl> Message-ID: <1134850148.22855.6.camel@xpc.home.erwinrol.com> Yeah that rebuild was almost as much wasted energy as writing a mail about a rebuild that wasted energy (or replying on a mail about a rebuilt that wasted energy) ;-) - Erwin On Sat, 2005-12-17 at 20:58 +0100, Tomasz K?oczko wrote: > Dnia 17-12-2005, sob o godzinie 10:40 -0500, Build System napisa?(a): > [..] > > logwatch-7.1-4.1 > > ---------------- > > * Fri Dec 09 2005 Jesse Keating > > - rebuilt > [..] > > mailcap-2.1.19-1.1 > > ------------------ > > * Fri Dec 09 2005 Jesse Keating > > - rebuilt > > > > man-pages-cs-0.16-5.1 > > --------------------- > > * Fri Dec 09 2005 Jesse Keating > > - rebuilt > [..and all other man-pages-*..] > > Sorry but what is the sense rebuilding this noarch packages. > IMO this only waste of time and energy. > > > perl-Devel-Symdump-2.03-20.1 > > ---------------------------- > > * Fri Dec 16 2005 Jesse Keating > > - rebuilt for new gcj > [..and all other perl modules. Specialy packed in noarch packages..] > > Next: how chages in libgcj affects perl modules ??? specialy noarch perl > modules ? :-o > This next plain waste of time and energy for supply build systems. > > kloczek > From seanlkml at sympatico.ca Sat Dec 17 20:18:42 2005 From: seanlkml at sympatico.ca (Sean) Date: Sat, 17 Dec 2005 15:18:42 -0500 (EST) Subject: bittorrent in core? what frontend? In-Reply-To: <604aa7910512171204s4e8caf24k91a907f03a208294@mail.gmail.com> References: <1134662961.28842.128.camel@greebo> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> <1134846931.24472.78.camel@yoda.loki.me> <35487.10.10.10.28.1134847155.squirrel@linux1> <1134847663.24472.82.camel@yoda.loki.me> <1134849284.22444.11.camel@hamburger.booze> <604aa7910512171204s4e8caf24k91a907f03a208294@mail.gmail.com> Message-ID: On Sat, December 17, 2005 3:04 pm, Jeff Spaleta said: > There's a big difference between users delibrately deciding to poke > holes in their firewall, and having the operating system let any > application automatically poke holes without authentication to allow > the action. > > I'd be perfectly fine with a mechanism that applications could use > which first request permissions to open ports from the user and > notified the user as to which application was making the request, > before ports were dynamically opened. Well, the user is going to have to do something explicit to open up the firewall on the local machine. But the fact is, if the feature is enabled on the router, there is nothing Fedora can do to stop some malicious program from using it. So all you're doing is stopping trusted programs from using the feature and its still available to be used by untrusted apps. The feature really must be disabled on the router itself if you don't like it. Sean From seg at haxxed.com Sat Dec 17 20:24:56 2005 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 17 Dec 2005 14:24:56 -0600 Subject: bittorrent in core? what frontend? In-Reply-To: <604aa7910512171204s4e8caf24k91a907f03a208294@mail.gmail.com> References: <1134662961.28842.128.camel@greebo> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> <1134846931.24472.78.camel@yoda.loki.me> <35487.10.10.10.28.1134847155.squirrel@linux1> <1134847663.24472.82.camel@yoda.loki.me> <1134849284.22444.11.camel@hamburger.booze> <604aa7910512171204s4e8caf24k91a907f03a208294@mail.gmail.com> Message-ID: <1134851097.22444.38.camel@hamburger.booze> > There's a big difference between users delibrately deciding to poke > holes in their firewall, and having the operating system let any > application automatically poke holes without authentication to allow > the action. They deliberately decide to poke holes in their firewall by running a UPNP enabled application. > I'd be perfectly fine with a mechanism that applications could use > which first request permissions to open ports from the user and > notified the user as to which application was making the request, > before ports were dynamically opened. We're talking about an embedded router with no user interface here. You can't do the user prompting there. Which leaves you with doing it client side. I've been toying with writing a NAT-PMP server, and at least with that protocol client support really belongs in a system wide daemon. Like Avahi. This would give you a point at which to prompt the user. But there's nothing in the protocol that ensures a program can't just bypass all that and talk the protocol directly. -------------- 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 seanlkml at sympatico.ca Sat Dec 17 20:22:35 2005 From: seanlkml at sympatico.ca (Sean) Date: Sat, 17 Dec 2005 15:22:35 -0500 (EST) Subject: bittorrent in core? what frontend? In-Reply-To: <1134850359.22444.26.camel@hamburger.booze> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> <1134822155.10233.6.camel@locolhost.localdomain> <41673.10.10.10.28.1134823273.squirrel@linux1> <1134850359.22444.26.camel@hamburger.booze> Message-ID: On Sat, December 17, 2005 3:12 pm, Callum Lerwick said: > Actually, when you're talking about processes on the local machine, > firewall rules are a totally hackish way of going about this. > > What you want to do, is have some kind of local ACL that says what > processes and users can bind to what ports. This would solve a whole > mess of security problems. (Look around, a great many server daemons > have to be started as root, for the mere fact they want to bind to ports > <1024.) Instead of firewalling, make the kernel disallow processes from > even binding listen ports at all in the first place. Yes, I believe ports are given a security context as well, although I don't know how fine grained it is or if you still have to deal with iptables rules in addition. Sean > I know back when I was playing with grsecurity years ago, it had a > feature like this. It had group-based access control, you could set up a > certain group and say "This group can not bind listen ports" and even > "This group can't make outgoing connections" too. Or you could turn it > around and say "Only this group can bind to ports" etc. > > It had some weird side effects though. IIRC various things wanted to > bind to loopback... From kloczek at zie.pg.gda.pl Sat Dec 17 20:25:40 2005 From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=) Date: Sat, 17 Dec 2005 21:25:40 +0100 Subject: rawhide report: 20051217 changes In-Reply-To: <1134850148.22855.6.camel@xpc.home.erwinrol.com> References: <200512171540.jBHFeR3C001817@porkchop.devel.redhat.com> <1134849484.21177.25.camel@test1.zie.pg.gda.pl> <1134850148.22855.6.camel@xpc.home.erwinrol.com> Message-ID: <1134851140.21177.31.camel@test1.zie.pg.gda.pl> Dnia 17-12-2005, sob o godzinie 21:09 +0100, Erwin Rol napisa?(a): > Yeah that rebuild was almost as much wasted energy as writing a mail > about a rebuild that wasted energy (or replying on a mail about a > rebuilt that wasted energy) ;-) Better will be have one build system which will only rebuild all packages for show only which packages are stop build correctly during some partial upgrade without generate any packages fiels otside build system. Sometimes it is hard to predict some "interferencs"/consequences of upgrade A packages set for B packages set on build stage. In this cases better will be check this "in combat" by performe kind of "control rebuild". kloczek From jspaleta at gmail.com Sat Dec 17 20:31:04 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 17 Dec 2005 15:31:04 -0500 Subject: bittorrent in core? what frontend? In-Reply-To: <1134851097.22444.38.camel@hamburger.booze> References: <1134662961.28842.128.camel@greebo> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> <1134846931.24472.78.camel@yoda.loki.me> <35487.10.10.10.28.1134847155.squirrel@linux1> <1134847663.24472.82.camel@yoda.loki.me> <1134849284.22444.11.camel@hamburger.booze> <604aa7910512171204s4e8caf24k91a907f03a208294@mail.gmail.com> <1134851097.22444.38.camel@hamburger.booze> Message-ID: <604aa7910512171231u189d70abj7af6e739a178698d@mail.gmail.com> On 12/17/05, Callum Lerwick wrote: > They deliberately decide to poke holes in their firewall by running a > UPNP enabled application. And when the user doesn't know its upnp enabled application? Or when the application is malicious and misrepresents what its suppose to be doing and does upnp operations withuot clear consent from the user? -jef From stephen_pollei at comcast.net Sat Dec 17 20:28:13 2005 From: stephen_pollei at comcast.net (Stephen Pollei) Date: 17 Dec 2005 12:28:13 -0800 Subject: bittorrent in core? what frontend? In-Reply-To: <1134834793.13361.3.camel@locolhost.localdomain> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> <1134822155.10233.6.camel@locolhost.localdomain> <41673.10.10.10.28.1134823273.squirrel@linux1> <1134834793.13361.3.camel@locolhost.localdomain> Message-ID: <1134851294.1004.19.camel@fury> On Sat, 2005-12-17 at 07:53, Michael A. Peters wrote: > On Sat, 2005-12-17 at 07:41 -0500, Sean wrote: > > You don't want a static > > firewall rule for a process that is only running occasionally. No, what > > you want is an appropriate firewall rule set only for the time that BT is > > actually running. Anything else is a security risk in itself. Actually shouldn't the strict selinux policy cover this type of thing much better. Not only just while BT is running, but only BT the app can listen on that port range? > Oh I see what you are saying. > When trusted application foo is being run by user in trusted group bar > (or open for any user) - the firewall will open ports xxxx to yyyy > should foo request they be opened - for the duration that foo is > running. yes and that request should just be the bind(sockfd, my_addr, addrlen); The kernel should be able to decide to grant that request based on the information it has being a "trusted" app(selinux context label), run by trusted user(uid,gid,selinux domain). > > That would be slick. It would be slicker if only the BT app could use those ports and you didn't have to dynamically punch holes in the firewall. -- http://dmoz.org/profiles/pollei.html http://sourceforge.net/users/stephen_pollei/ http://www.orkut.com/Profile.aspx?uid=2455954990164098214 http://stephen_pollei.home.comcast.net/ http://www.biglumber.com/x/web?sn=Stephen+Pollei https://keyserver-beta.pgp.com/vkd/DownloadKey.event?keyid=0x910F6BB54A7D9677 GPG Key fingerprint = EF6F 1486 EC27 B5E7 E6E1 3C01 910F 6BB5 4A7D 9677 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seanlkml at sympatico.ca Sat Dec 17 20:39:11 2005 From: seanlkml at sympatico.ca (Sean) Date: Sat, 17 Dec 2005 15:39:11 -0500 (EST) Subject: bittorrent in core? what frontend? In-Reply-To: <604aa7910512171231u189d70abj7af6e739a178698d@mail.gmail.com> References: <1134662961.28842.128.camel@greebo> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> <1134846931.24472.78.camel@yoda.loki.me> <35487.10.10.10.28.1134847155.squirrel@linux1> <1134847663.24472.82.camel@yoda.loki.me> <1134849284.22444.11.camel@hamburger.booze> <604aa7910512171204s4e8caf24k91a907f03a208294@mail.gmail.com> <1134851097.22444.38.camel@hamburger.booze> <604aa7910512171231u189d70abj7af6e739a178698d@mail.gmail.com> Message-ID: On Sat, December 17, 2005 3:31 pm, Jeff Spaleta said: > On 12/17/05, Callum Lerwick wrote: >> They deliberately decide to poke holes in their firewall by running a >> UPNP enabled application. > > And when the user doesn't know its upnp enabled application? Or when > the application is malicious and misrepresents what its suppose to be > doing and does upnp operations withuot clear consent from the user? Well what if the program does "rm -rf ~/*" without clear consent from the user? At some point you either trust your application or you don't. The fallback here is that currently only root can alter the iptable firewall rules on the local machine, so even if a malicious program does use UPnP no packets will arrive at the local machine because they will be filtered by the local firewall. But the point has to be made again, nothing we're talking about here changes the situation of malicious code. _Today_ as Fedora exists out of the box, a malicious program can enable UPnP on a router that has it enabled. All we're talking about is using that facility as it was meant to be used, by _trusted_ application like the bit torrent client supplied with the distribution. Sean From seanlkml at sympatico.ca Sat Dec 17 20:41:42 2005 From: seanlkml at sympatico.ca (Sean) Date: Sat, 17 Dec 2005 15:41:42 -0500 (EST) Subject: bittorrent in core? what frontend? In-Reply-To: <1134851294.1004.19.camel@fury> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> <1134822155.10233.6.camel@locolhost.localdomain> <41673.10.10.10.28.1134823273.squirrel@linux1> <1134834793.13361.3.camel@locolhost.localdomain> <1134851294.1004.19.camel@fury> Message-ID: On Sat, December 17, 2005 3:28 pm, Stephen Pollei said: >> That would be slick. > It would be slicker if only the BT app could use those ports and you > didn't have to dynamically punch holes in the firewall. Yes, but you may have to punch holes in the firewall _as well_. I don't think selinux security context would override any local firewall rules which (as they stand today) lock down all ports that aren't explicitly enabled for a service. Sean From seg at haxxed.com Sat Dec 17 20:49:02 2005 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 17 Dec 2005 14:49:02 -0600 Subject: bittorrent in core? what frontend? In-Reply-To: <604aa7910512171231u189d70abj7af6e739a178698d@mail.gmail.com> References: <1134662961.28842.128.camel@greebo> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> <1134846931.24472.78.camel@yoda.loki.me> <35487.10.10.10.28.1134847155.squirrel@linux1> <1134847663.24472.82.camel@yoda.loki.me> <1134849284.22444.11.camel@hamburger.booze> <604aa7910512171204s4e8caf24k91a907f03a208294@mail.gmail.com> <1134851097.22444.38.camel@hamburger.booze> <604aa7910512171231u189d70abj7af6e739a178698d@mail.gmail.com> Message-ID: <1134852543.22444.47.camel@hamburger.booze> On Sat, 2005-12-17 at 15:31 -0500, Jeff Spaleta wrote: > And when the user doesn't know its upnp enabled application? Or when > the application is malicious and misrepresents what its suppose to be > doing and does upnp operations withuot clear consent from the user? Then you have far worse things to worry about than port forwarding. It could rm -rfv ~/*. It can still make outgoing connections to a server and accept commands, and upload personal info. It can still participate in a DDoS. Etc. Once malicious software has made it in behind your firewall, you've already lost. Game over man. Nuke the machine from orbit. Some port forwards are the least of your worries at this point. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From seg at haxxed.com Sat Dec 17 20:55:09 2005 From: seg at haxxed.com (Callum Lerwick) Date: Sat, 17 Dec 2005 14:55:09 -0600 Subject: bittorrent in core? what frontend? In-Reply-To: <34008.10.10.10.28.1134852102.squirrel@linux1> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> <1134822155.10233.6.camel@locolhost.localdomain> <41673.10.10.10.28.1134823273.squirrel@linux1> <1134834793.13361.3.camel@locolhost.localdomain> <1134851294.1004.19.camel@fury> <34008.10.10.10.28.1134852102.squirrel@linux1> Message-ID: <1134852909.22444.52.camel@hamburger.booze> > Yes, but you may have to punch holes in the firewall _as well_. I don't > think selinux security context would override any local firewall rules > which (as they stand today) lock down all ports that aren't explicitly > enabled for a service. Thats why you should be using selinux to prevent unwanted port bindings system wide. Disable firewalling in this case. Or at least limit it to ports <1024 or something. There's still the annoying question of ports the *kernel itself* is listening to. NFS serving likes to do this, and use random ports just above 1024 to do it. ;P -------------- 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 Sat Dec 17 20:55:47 2005 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 17 Dec 2005 12:55:47 -0800 Subject: rawhide report: 20051217 changes In-Reply-To: <1134849484.21177.25.camel@test1.zie.pg.gda.pl> References: <200512171540.jBHFeR3C001817@porkchop.devel.redhat.com> <1134849484.21177.25.camel@test1.zie.pg.gda.pl> Message-ID: <1134852947.24472.91.camel@yoda.loki.me> On Sat, 2005-12-17 at 20:58 +0100, Tomasz K?oczko wrote: > Sorry but what is the sense rebuilding this noarch packages. > IMO this only waste of time and energy. > > > perl-Devel-Symdump-2.03-20.1 > > ---------------------------- > > * Fri Dec 16 2005 Jesse Keating > > - rebuilt for new gcj > [..and all other perl modules. Specialy packed in noarch packages..] > > Next: how chages in libgcj affects perl modules ??? specialy noarch perl > modules ? :-o > This next plain waste of time and energy for supply build systems. Then I guess it is a good thing that it was my time and energy instead of yours. It was a scripted rebuild that had a few flaws. 1) the script failed to catch noarch packages that aren't built w/ gcc, and 2) the changelog bump had 'gcj' instead of 'gcc' in it due to not being changed after the java rebuilds. -- Jesse Keating Release Engineer: Fedora From jkeating at j2solutions.net Sat Dec 17 20:58:49 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 17 Dec 2005 12:58:49 -0800 Subject: bittorrent in core? what frontend? In-Reply-To: <33113.10.10.10.28.1134850722.squirrel@linux1> References: <1134662961.28842.128.camel@greebo> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> <1134846931.24472.78.camel@yoda.loki.me> <35487.10.10.10.28.1134847155.squirrel@linux1> <1134847663.24472.82.camel@yoda.loki.me> <1134849284.22444.11.camel@hamburger.booze> <604aa7910512171204s4e8caf24k91a907f03a208294@mail.gmail.com> <33113.10.10.10.28.1134850722.squirrel@linux1> Message-ID: <1134853129.24472.94.camel@yoda.loki.me> On Sat, 2005-12-17 at 15:18 -0500, Sean wrote: > Well, the user is going to have to do something explicit to open up the > firewall on the local machine. Not if it scripted and/or plugged into system-config-securitylevel or whatever it is we use to manage the firewall locally these days. > But the fact is, if the feature is enabled on the router, there is nothing > Fedora can do to stop some malicious program from using it. So all > you're doing is stopping trusted programs from using the feature and its > still available to be used by untrusted apps. The feature really must be > disabled on the router itself if you don't like it. Just because it is enabled on the router doesn't mean that we should preconfigure applications to exploit it. Bad call. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From jkeating at j2solutions.net Sat Dec 17 21:01:55 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 17 Dec 2005 13:01:55 -0800 Subject: bittorrent in core? what frontend? In-Reply-To: <34004.10.10.10.28.1134851951.squirrel@linux1> References: <1134662961.28842.128.camel@greebo> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> <1134846931.24472.78.camel@yoda.loki.me> <35487.10.10.10.28.1134847155.squirrel@linux1> <1134847663.24472.82.camel@yoda.loki.me> <1134849284.22444.11.camel@hamburger.booze> <604aa7910512171204s4e8caf24k91a907f03a208294@mail.gmail.com> <1134851097.22444.38.camel@hamburger.booze> <604aa7910512171231u189d70abj7af6e739a178698d@mail.gmail.com> <34004.10.10.10.28.1134851951.squirrel@linux1> Message-ID: <1134853315.24472.95.camel@yoda.loki.me> On Sat, 2005-12-17 at 15:39 -0500, Sean wrote: > But the point has to be made again, nothing we're talking about here > changes the situation of malicious code. _Today_ as Fedora exists out of > the box, a malicious program can enable UPnP on a router that has it > enabled. All we're talking about is using that facility as it was meant > to be used, by _trusted_ application like the bit torrent client supplied > with the distribution. And here I thought we were discussing the merrits of having the bt client default to upnp enabled. I would rather it be disabled, and let the user decide to use risky features. Secure by default. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From seanlkml at sympatico.ca Sat Dec 17 21:04:44 2005 From: seanlkml at sympatico.ca (Sean) Date: Sat, 17 Dec 2005 16:04:44 -0500 (EST) Subject: bittorrent in core? what frontend? In-Reply-To: <1134853129.24472.94.camel@yoda.loki.me> References: <1134662961.28842.128.camel@greebo> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> <1134846931.24472.78.camel@yoda.loki.me> <35487.10.10.10.28.1134847155.squirrel@linux1> <1134847663.24472.82.camel@yoda.loki.me> <1134849284.22444.11.camel@hamburger.booze> <604aa7910512171204s4e8caf24k91a907f03a208294@mail.gmail.com> <33113.10.10.10.28.1134850722.squirrel@linux1> <1134853129.24472.94.camel@yoda.loki.me> Message-ID: On Sat, December 17, 2005 3:58 pm, Jesse Keating said: >> Well, the user is going to have to do something explicit to open up the >> firewall on the local machine. > > Not if it scripted and/or plugged into system-config-securitylevel or > whatever it is we use to manage the firewall locally these days. Well, we won't script it then. > Just because it is enabled on the router doesn't mean that we should > preconfigure applications to exploit it. Bad call. > It's a low risk feature that adds signficant ease of use for the user. You haven't shown at all how it could be exploited. Sean From seanlkml at sympatico.ca Sat Dec 17 21:09:58 2005 From: seanlkml at sympatico.ca (Sean) Date: Sat, 17 Dec 2005 16:09:58 -0500 (EST) Subject: bittorrent in core? what frontend? In-Reply-To: <1134853315.24472.95.camel@yoda.loki.me> References: <1134662961.28842.128.camel@greebo> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> <1134846931.24472.78.camel@yoda.loki.me> <35487.10.10.10.28.1134847155.squirrel@linux1> <1134847663.24472.82.camel@yoda.loki.me> <1134849284.22444.11.camel@hamburger.booze> <604aa7910512171204s4e8caf24k91a907f03a208294@mail.gmail.com> <1134851097.22444.38.camel@hamburger.booze> <604aa7910512171231u189d70abj7af6e739a178698d@mail.gmail.com> <34004.10.10.10.28.1134851951.squirrel@linux1> <1134853315.24472.95.camel@yoda.loki.me> Message-ID: On Sat, December 17, 2005 4:01 pm, Jesse Keating said: > And here I thought we were discussing the merrits of having the bt > client default to upnp enabled. I would rather it be disabled, and let > the user decide to use risky features. Secure by default. There is no significant risk added at all. If there is an exploit in the bit torrent client, it needs to have a security patch either way. Enabling the use of UPnP doesn't change that. But it would significantly improve the user experience of a large number of users that want to use it to download Fedora releases. The use of UPnP is actually an improvement over manually configured port settings because they're only in place while the client is being used. But as long as the feature is at least provided as an option, having it default to "off" isn't a big deal. Cheers, Sean From kloczek at zie.pg.gda.pl Sat Dec 17 21:12:24 2005 From: kloczek at zie.pg.gda.pl (Tomasz =?iso-8859-2?Q?K=B3oczko?=) Date: Sat, 17 Dec 2005 22:12:24 +0100 Subject: rawhide report: 20051217 changes In-Reply-To: <1134852947.24472.91.camel@yoda.loki.me> References: <200512171540.jBHFeR3C001817@porkchop.devel.redhat.com> <1134849484.21177.25.camel@test1.zie.pg.gda.pl> <1134852947.24472.91.camel@yoda.loki.me> Message-ID: <1134853944.21177.41.camel@test1.zie.pg.gda.pl> Dnia 17-12-2005, sob o godzinie 12:55 -0800, Jesse Keating napisa?(a): [..] > > Next: how chages in libgcj affects perl modules ??? specialy noarch perl > > modules ? :-o > > This next plain waste of time and energy for supply build systems. > > Then I guess it is a good thing that it was my time and energy instead > of yours. So it mean "subscribe to fedora-devel-list it is waste of time" ? > It was a scripted rebuild that had a few flaws. 1) the > script failed to catch noarch packages that aren't built w/ gcc, and 2) > the changelog bump had 'gcj' instead of 'gcc' in it due to not being > changed after the java rebuilds. So you know now (with my help or not) using this script it is bad methodology (If it is not clear a'm talking only about this) Consequences: instead reply for not sending any kind of answers better will be spend this time on rething rebuilding methodology. I'm not asking how scripted rebuild work. I'm asking using very simple and elementar questions. If you don't want anwer on this or not want chage this stupid scripts simple better not wast (my an your) time for reply :> kloczek From stephen_pollei at comcast.net Sat Dec 17 21:10:22 2005 From: stephen_pollei at comcast.net (Stephen Pollei) Date: 17 Dec 2005 13:10:22 -0800 Subject: bittorrent in core? what frontend? In-Reply-To: <1134850359.22444.26.camel@hamburger.booze> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> <1134822155.10233.6.camel@locolhost.localdomain> <41673.10.10.10.28.1134823273.squirrel@linux1> <1134850359.22444.26.camel@hamburger.booze> Message-ID: <1134853824.1004.49.camel@fury> On Sat, 2005-12-17 at 12:12, Callum Lerwick wrote: > Actually, when you're talking about processes on the local machine, > firewall rules are a totally hackish way of going about this. Actually it's having to dynamically alter your policy, because of the weakness of it's expression that is hacky. Between selinux and netfilter you should be able to precisely state your policy. The only thing is his UPnP nternet Gateway Device (IGD) controller via Dbus should be a userland process and this deputy should be able to inspect the selinux domain of the requesting process and based it's decisions on that as well. > What you want to do, is have some kind of local ACL that says what > processes and users can bind to what ports. > Can selinux do this? If not, it should. In theory yes, of course some people are disabling even the targeted policy and the strict policy might not yet be ready for primetime. You'd need the strict policy if you don't want most user's processes running as unconfined_t . How is the work on getting strict policy working well going anyway? http://www.netfilter.org/ http://www.nsa.gov/selinux/ http://selinux.sourceforge.net/ http://www.knoxscape.com/Upnp/NAT.htm http://www.microsoft.com/technet/prodtechnol/winxppro/support/upnp01.mspx http://en.wikipedia.org/wiki/Internet_Gateway_Device http://www.upnp.org/standardizeddcps/igd.asp -- http://dmoz.org/profiles/pollei.html http://sourceforge.net/users/stephen_pollei/ http://www.orkut.com/Profile.aspx?uid=2455954990164098214 http://stephen_pollei.home.comcast.net/ http://www.biglumber.com/x/web?sn=Stephen+Pollei https://keyserver-beta.pgp.com/vkd/DownloadKey.event?keyid=0x910F6BB54A7D9677 GPG Key fingerprint = EF6F 1486 EC27 B5E7 E6E1 3C01 910F 6BB5 4A7D 9677 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jkeating at j2solutions.net Sat Dec 17 21:17:54 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Sat, 17 Dec 2005 13:17:54 -0800 Subject: bittorrent in core? what frontend? In-Reply-To: <34447.10.10.10.28.1134853484.squirrel@linux1> References: <1134662961.28842.128.camel@greebo> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> <1134846931.24472.78.camel@yoda.loki.me> <35487.10.10.10.28.1134847155.squirrel@linux1> <1134847663.24472.82.camel@yoda.loki.me> <1134849284.22444.11.camel@hamburger.booze> <604aa7910512171204s4e8caf24k91a907f03a208294@mail.gmail.com> <33113.10.10.10.28.1134850722.squirrel@linux1> <1134853129.24472.94.camel@yoda.loki.me> <34447.10.10.10.28.1134853484.squirrel@linux1> Message-ID: <1134854274.24472.103.camel@yoda.loki.me> On Sat, 2005-12-17 at 16:04 -0500, Sean wrote: > It's a low risk feature that adds signficant ease of use for the user. > You haven't shown at all how it could be exploited. If I knew how it could, I would have alerted upstream and vendors to get a CVE assigned and a fix coordinated. Unfortunately not all folks who discover flaws act in this way. With a port forward, any traffic at all can be pushed to the client. Who knows what kind of overflows or whatnot may be in the client software, that could lead to something which the client has rights to do, such as 'remove your temp files, which are ~/*'. My point is that forwarding ports is a risk. Sure it could just wipe your user files, but maybe it could do more. I don't know, I am not a security expert. Forwarded ports are much different than established/related packets. Unassociated traffic can come in at will. This kind of risk needs to be something a USER assumes, not a distribution. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From jkeating at redhat.com Sat Dec 17 21:22:19 2005 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 17 Dec 2005 13:22:19 -0800 Subject: rawhide report: 20051217 changes In-Reply-To: <1134853944.21177.41.camel@test1.zie.pg.gda.pl> References: <200512171540.jBHFeR3C001817@porkchop.devel.redhat.com> <1134849484.21177.25.camel@test1.zie.pg.gda.pl> <1134852947.24472.91.camel@yoda.loki.me> <1134853944.21177.41.camel@test1.zie.pg.gda.pl> Message-ID: <1134854539.24472.108.camel@yoda.loki.me> On Sat, 2005-12-17 at 22:12 +0100, Tomasz K?oczko wrote: > So it mean "subscribe to fedora-devel-list it is waste of time" ? I'm sorry, I don't follow this? > > It was a scripted rebuild that had a few flaws. 1) the > > script failed to catch noarch packages that aren't built w/ gcc, and 2) > > the changelog bump had 'gcj' instead of 'gcc' in it due to not being > > changed after the java rebuilds. > > So you know now (with my help or not) using this script it is bad > methodology (If it is not clear a'm talking only about this) > Consequences: instead reply for not sending any kind of answers better > will be spend this time on rething rebuilding methodology. I really don't know what kind of answers you were looking for. I explained why the were upgraded, and why the changelog had an invalid entry. What more can I say? > I'm not asking how scripted rebuild work. I'm asking using very simple > and elementar questions. If you don't want anwer on this or not want > chage this stupid scripts simple better not wast (my an your) time for > reply :> Again, I answered the questions I saw: Q: Why were noarch packages rebuilt? A: The script I used failed to check for noarch. Q: Why was 'gcj' referenced in the changelog for perl packages? A: The script had an old entry used when dealing w/ java packages. I did not see any further questions in the email I replied to, and I tried to answer them in the most honest way possible. -- Jesse Keating Release Engineer: Fedora From seanlkml at sympatico.ca Sat Dec 17 21:32:59 2005 From: seanlkml at sympatico.ca (Sean) Date: Sat, 17 Dec 2005 16:32:59 -0500 (EST) Subject: bittorrent in core? what frontend? In-Reply-To: <1134854274.24472.103.camel@yoda.loki.me> References: <1134662961.28842.128.camel@greebo> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> <1134846931.24472.78.camel@yoda.loki.me> <35487.10.10.10.28.1134847155.squirrel@linux1> <1134847663.24472.82.camel@yoda.loki.me> <1134849284.22444.11.camel@hamburger.booze> <604aa7910512171204s4e8caf24k91a907f03a208294@mail.gmail.com> <33113.10.10.10.28.1134850722.squirrel@linux1> <1134853129.24472.94.camel@yoda.loki.me> <34447.10.10.10.28.1134853484.squirrel@linux1> <1134854274.24472.103.camel@yoda.loki.me> Message-ID: On Sat, December 17, 2005 4:17 pm, Jesse Keating said: > On Sat, 2005-12-17 at 16:04 -0500, Sean wrote: >> It's a low risk feature that adds signficant ease of use for the user. >> You haven't shown at all how it could be exploited. > > If I knew how it could, I would have alerted upstream and vendors to get > a CVE assigned and a fix coordinated. Unfortunately not all folks who > discover flaws act in this way. > > With a port forward, any traffic at all can be pushed to the client. > Who knows what kind of overflows or whatnot may be in the client > software, that could lead to something which the client has rights to > do, such as 'remove your temp files, which are ~/*'. My point is that > forwarding ports is a risk. Sure it could just wipe your user files, > but maybe it could do more. I don't know, I am not a security expert. > Forwarded ports are much different than established/related packets. > Unassociated traffic can come in at will. This kind of risk needs to be > something a USER assumes, not a distribution. > That's a pretty weak argument. Many users are connected directly to the internet and thus when they start the application they assume the risk. It's the exact same thing if they install a router that has UPnP enabled on it; they've assumed the risk. But so long as you're happy to include the feature if its disabled by default we really have no reason to argue. Sean From green at redhat.com Sat Dec 17 22:15:16 2005 From: green at redhat.com (Anthony Green) Date: Sat, 17 Dec 2005 14:15:16 -0800 Subject: Azureus (Was: bittorrent in core? what frontend?) In-Reply-To: <1134668805.3312.33.camel@localhost.localdomain> References: <1134662961.28842.128.camel@greebo> <40142.10.10.10.28.1134664763.squirrel@linux1> <1134668805.3312.33.camel@localhost.localdomain> Message-ID: <1134857717.3244.22.camel@localhost.localdomain> On Thu, 2005-12-15 at 09:46 -0800, Anthony Green wrote: > I will give it another go once a gcj4.1 built SWT (from Eclipse) lands > in rawhide. There have been many Classpath bug fixes over the past > year, so everybody cross your fingers. Just FYI, I've packaged Azureus for rawhide with our Free stack. Here's a screenshot: http://spindazzle.org/pics/azureus-on-gcj4-2005-12-17.png There are still bugs preventing it from working properly. Hopefully I can get some of the gcj and GNU Classpath hackers to help sort out the remaining issues and we can push it into Extras sometime. AG From mpeters at mac.com Sun Dec 18 01:42:49 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sat, 17 Dec 2005 17:42:49 -0800 Subject: Azureus (Was: bittorrent in core? what frontend?) In-Reply-To: <1134857717.3244.22.camel@localhost.localdomain> References: <1134662961.28842.128.camel@greebo> <40142.10.10.10.28.1134664763.squirrel@linux1> <1134668805.3312.33.camel@localhost.localdomain> <1134857717.3244.22.camel@localhost.localdomain> Message-ID: <1134870169.13361.23.camel@locolhost.localdomain> On Sat, 2005-12-17 at 14:15 -0800, Anthony Green wrote: > On Thu, 2005-12-15 at 09:46 -0800, Anthony Green wrote: > > I will give it another go once a gcj4.1 built SWT (from Eclipse) lands > > in rawhide. There have been many Classpath bug fixes over the past > > year, so everybody cross your fingers. > > Just FYI, I've packaged Azureus for rawhide with our Free stack. Here's > a screenshot: > > http://spindazzle.org/pics/azureus-on-gcj4-2005-12-17.png That does not look like the ugly java applications I've used :) From sundaram at redhat.com Sun Dec 18 01:49:55 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Sun, 18 Dec 2005 07:19:55 +0530 Subject: Azureus (Was: bittorrent in core? what frontend?) In-Reply-To: <1134870169.13361.23.camel@locolhost.localdomain> References: <1134662961.28842.128.camel@greebo> <40142.10.10.10.28.1134664763.squirrel@linux1> <1134668805.3312.33.camel@localhost.localdomain> <1134857717.3244.22.camel@localhost.localdomain> <1134870169.13361.23.camel@locolhost.localdomain> Message-ID: <43A4C043.5090201@redhat.com> Michael A. Peters wrote: >On Sat, 2005-12-17 at 14:15 -0800, Anthony Green wrote: > > >>On Thu, 2005-12-15 at 09:46 -0800, Anthony Green wrote: >> >> >>>I will give it another go once a gcj4.1 built SWT (from Eclipse) lands >>>in rawhide. There have been many Classpath bug fixes over the past >>>year, so everybody cross your fingers. >>> >>> >>Just FYI, I've packaged Azureus for rawhide with our Free stack. Here's >>a screenshot: >> >> http://spindazzle.org/pics/azureus-on-gcj4-2005-12-17.png >> >> > >That does not look like the ugly java applications I've used :) > > > It demonstrates the improving maturity of a Free Java platform power by GCJ. Congrats guys! regards Rahul From jkeating at redhat.com Sun Dec 18 07:43:16 2005 From: jkeating at redhat.com (Jesse Keating) Date: Sat, 17 Dec 2005 23:43:16 -0800 Subject: More mass rebuilds for GCC Message-ID: <1134891796.5262.19.camel@ender> As you'll notice, there will be lots more packages bumped for the rebase to gcc. Most completed today, but we'll be working through a list of failures over the next couple days. Things will still be in a bit of flux, but we're working on it. Java is still being worked on too. Getting the java stack built with gcj is a great accomplishment and I really respect our java and gcj team for putting in the work to further the free java. Please bare with us as we finalize the development changes necessary to accomplish this task. -- Jesse Keating Release Engineer: Fedora From dragoran at feuerpokemon.de Sun Dec 18 07:48:07 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Sun, 18 Dec 2005 08:48:07 +0100 Subject: gnome 2.12 for fc4? In-Reply-To: <1134848345.752.7.camel@tuxhugger> References: <43A3E646.4070100@feuerpokemon.de> <1134848345.752.7.camel@tuxhugger> Message-ID: <43A51437.4000602@feuerpokemon.de> Peter Gordon schrieb: >On Sat, 2005-12-17 at 11:19 +0100, dragoran wrote: > > >>kde 3.5 was released as an update for fc4. >>but what about gnome 2.12? >>fc5 will use gnome 2.14 while fc4 still uses gnome 2.10. >>so any reasons for not shipping gnome 2.12? (I know that it will require >>a new gtk and cairo) >> >> > >There was an article about this on FedoraNews soon after the release of >GNOME 2.12: > >Essentially, you configure your system to use a third-party repository >for all of the GNOME 2.12 stuff. > >Please note that is probably entirely unsupported by the Fedora dev >team, and it can easily break your system if you're not very careful. >I've not tried this, so I can't comment on it further. > > I hate replacing core packages with third party ones. From rc040203 at freenet.de Sun Dec 18 07:55:34 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Sun, 18 Dec 2005 08:55:34 +0100 Subject: kdebindings-3.5.0-0.1.fc4 pull in ruby Message-ID: <1134892535.30243.344.camel@mccallum.corsepiu.local> Hi, The new FC4 kdebindings-3.5.0-0.1.fc4 rpms depend on ruby - Why? Looks very much like a bug to me. Ralf From buildsys at redhat.com Sun Dec 18 08:34:36 2005 From: buildsys at redhat.com (Build System) Date: Sun, 18 Dec 2005 03:34:36 -0500 Subject: rawhide report: 20051218 changes Message-ID: <200512180834.jBI8YatH014352@porkchop.devel.redhat.com> New package xscreensaver X screen saver and locker Updated Packages: 4Suite-1.0-10.b1 ---------------- * Fri Dec 16 2005 Jesse Keating - 1.0-10.b1 - rebuild for new gcc MAKEDEV-3.20-1 -------------- * Fri Dec 16 2005 Nalin Dahyabhai 3.20-1 - update to 28 November devices-2.6+.txt: - rename ttyUB* to rfcomm* - rename cuub* to curf* - add ttyPSC* - add ttyAT* - add rfd* * Fri Dec 09 2005 Jesse Keating - rebuilt NetworkManager-0.5.1-5.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt PyXML-0.8.4-3.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt SDL-1.2.9-2.1.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt aspell-cs-50:0.51-3.1 --------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj aspell-pl-50:0.51-5.1 --------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj authconfig-5.1.0-1 ------------------ * Sat Dec 17 2005 Tomas Mraz - 5.1.0-1 - update only configuration files which settings were modified (#72290) * Mon Dec 05 2005 Tomas Mraz - 5.0.4-1 - don't ignore krb5realm command line option (#174838) - read dns_lookup_realm and dns_lookup_kdc values correctly - the PAM configuration is now written in system-auth-ac file which is then symlinked from system-auth, the symlink is not overwritten so local PAM configuration is now possible (#165342) * Mon Nov 07 2005 Tomas Mraz - 5.0.3-1 - add symlinks to python scripts in sbindir - don't override nullok setting from system-auth (#96996) compat-gcc-296-2.96-133 ----------------------- cpufreq-utils-1:0.3-1.1.19.1 ---------------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj * Fri Dec 09 2005 Jesse Keating - rebuilt cpuspeed-1:1.2.1-1.28 --------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj * Fri Dec 09 2005 Jesse Keating - rebuilt device-mapper-1.02.02-2.1 ------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt * Sat Dec 03 2005 Peter Jones - 1.02.02-2 - fix link path for libdevmapper-event.so * Fri Dec 02 2005 Peter Jones - 1.02.02-1 - update to 1.02.02 device-mapper-multipath-0.4.4-2.6.1 ----------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt dhcp-11:3.0.3-16.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt dmidecode-1:2.6-1.14 -------------------- * Fri Apr 15 2005 Florian La Roche - remove empty scripts * Wed Mar 02 2005 Dave Jones - Update to upstream 2.6 * Tue Mar 01 2005 Dave Jones - Rebuild for gcc4 dmidecode-1:2.7-1.22 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gnu-efi-3.0a-7.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt irqbalance-1:1.12-1.21.1 ------------------------ * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj * Fri Dec 09 2005 Jesse Keating - rebuilt kdelibs-6:3.5.0-3 ----------------- * Fri Dec 16 2005 Than Ngo 6:3.5.0-3 - add requires on several devel subpackages kernel-2.6.14-1.1771_FC5 ------------------------ * Sat Dec 17 2005 Dave Jones - 2.6.15-rc5-git7 * Fri Dec 16 2005 David Woodhouse - Update to fixed Cell pause_zero code * Fri Dec 16 2005 Dave Jones - 2.6.15-rc5-git6 kexec-tools-1.101-5.1 --------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj ksh-20050202-3.1 ---------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj lftp-3.3.5-1 ------------ * Thu Dec 15 2005 Jason Vas Dias> - 3.3.5-1 - Upgrade to version 3.3.5 - fix bug bz172376 : host lookups should use any address found after timeout libIDL-0.8.6-2.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libdaemon-0.10-1.1 ------------------ * Fri Dec 16 2005 Jesse Keating - 0.10-1.1 - rebuild on new gcc * Wed Dec 07 2005 Jason Vas Dias - 0.10-1 - Update to 0.10 * Thu Oct 20 2005 Alexander Larsson - 0.8-1 - Update to 0.8, move from extras to core, split out devel package libgconf-java-2.12.1-1.2.1.1 ---------------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj libglade-java-2.12.1-2.2.1.1 ---------------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj libgnomeprint22-2.12.1-3.1 -------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libgnomeprintui22-2.12.1-1.1 ---------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libgpg-error-1.1-1.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libgsf-1.13.3-2.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libibverbs-1.0.rc4-0.4265.1.FC5.1 --------------------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj libidn-0.6.0-1.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libiec61883-1.0.0-9.fc5.1 ------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libieee1284-0.2.9-3.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libjpeg-6b-36.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libmng-1.0.9-3.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libmthca-1.0.rc4-0.4265.1.FC5.1 ------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libmusicbrainz-2.1.1-1.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt libpfm-3.0-4.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libpng-2:1.2.8-2.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt libpng10-1.0.18-3.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt librtas-1.2.4-1.1 ----------------- libsdp-0.90-0.4265.1.FC5.1 -------------------------- libsilc-0:0.9.12-12.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libsoup-2.2.7-1.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libtermcap-2.0.8-42.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libtiff-3.7.4-3.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libunwind-0.98.2-3.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libuser-0.54.3-1.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt libwmf-0.2.8.4-2.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt libwpd-0.8.4-1.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libxklavier-2.0-3.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt libxml-1:1.8.17-13.1 -------------------- libxslt-1.1.15-1.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt linux-atm-2.5.0-0.20050118.2.1 ------------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt linuxdoc-tools-0.9.21-6.1 ------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt lksctp-tools-1.0.2-5.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt lm_sensors-2.9.1-5.1 -------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj * Tue Nov 08 2005 Phil Knirsch 2.9.1-5 - Fixed lm_sensors pwmconfig patch. lockdev-1.0.1-9.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt logrotate-3.7.3-2.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt longrun-1:0.9-1.12 ------------------ * Fri Dec 16 2005 Jesse Keating - rebuilt lrzsz-0.12.20-21.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt lslk-1.29-16.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt lsof-4.76-1.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt ltrace-0.3.36-3.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt lv-4.51-7.1 ----------- * Fri Dec 09 2005 Jesse Keating - rebuilt * Mon Oct 31 2005 Akira TAGOH - 4.51-7 - lv-+num-option.patch: applied a patch to allow +num option to jump to the specific line. - lv-fastio.patch: applied a patch to improve the performance to read the files. - lv-lfs.patch: applied a patch for Lerge File Summit support. * Mon Jul 11 2005 Akira TAGOH - 4.51-6 - lv-4.51-162372.patch: silence gcc warning. (#162372) lvm2-2.02.01-1.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt lynx-2.8.5-27.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt m2crypto-0.15-2.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt m4-1.4.4-1.1 ------------ * Fri Dec 09 2005 Jesse Keating - rebuilt macutils-2.0b3-32.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt magma-1.0.3-3.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt mailman-3:2.1.6-3.1 ------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj * Wed Dec 14 2005 Harald Hoyer - 3:2.1.5-36.fc4.1 - fix for bug #173139 (CVE-2005-3573 Mailman Denial of Service) * Fri Dec 09 2005 Jesse Keating - rebuilt mailx-8.1.1-44.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt make-1:3.80-8.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt mc-1:4.6.1a-5.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt mdadm-2.2-1.fc5.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt memtest86+-1.65-2.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt mesa-6.4-6 ---------- * Sun Dec 18 2005 Warren Togami - 6.4-6 - rebuild microcode_ctl-1:1.12-1.27.1 --------------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj * Fri Dec 09 2005 Jesse Keating - rebuilt mikmod-3.1.6-36.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt mingetty-1.07-5.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt minicom-2.1-1.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt mkbootdisk-1.5.2-5.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt mkinitrd-5.0.13-1.1 ------------------- * Fri Dec 16 2005 Jesse Keating - 5.0.13-1.1 - bump for gcc * Mon Dec 05 2005 Peter Jones - 5.0.13-1 - Updates for gcc 4.1 mktemp-3:1.5-23.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt mlocate-0.11-2.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt mod_auth_kerb-5.0-8.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt mod_auth_mysql-1:3.0.0-2.1 -------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt mod_auth_pgsql-2.0.1-9.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt mod_authz_ldap-0.26-6.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt mod_perl-2.0.2-3.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt mod_python-3.1.4-3.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt module-init-tools-3.2-0.pre9.1.1 -------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt mozplugger-1.7.3-2.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt mpage-2.5.4-5.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt mrtg-2.12.2-2.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt mt-st-0.9b-2.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt mtools-3.9.10-1.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt mtr-2:0.69-7.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt mtx-1.2.18-8.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt mutt-5:1.4.2.1-6.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt mx-2.0.6-2.1 ------------ * Fri Dec 09 2005 Jesse Keating - rebuilt nano-1.3.8-1.1 -------------- nasm-0.98.39-3.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt nautilus-sendto-0.4-5.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt nc-1.84-2.1 ----------- * Fri Dec 09 2005 Jesse Keating - rebuilt * Wed Dec 07 2005 Radek Vokal 1.84-2 - fix build requires * Fri Nov 18 2005 Radek Vokal 1.84-1 - follow upstream ncompress-4.2.4-43.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt ncpfs-2.2.6-1.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt ncurses-5.4-23.1 ---------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj * Thu Dec 01 2005 Petr Raszyk 5.4-23 - Rebuild. neon-0.24.7-10.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt net-snmp-5.2.2-4.1 ------------------ * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj net-tools-1.60-57.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt netatalk-4:2.0.3-4.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt netdump-0.7.14-1.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt netpbm-10.30-2.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt newt-0.52.2-1.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt newt-perl-1.08-9.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt nkf-2.05-1.1 ------------ * Fri Dec 09 2005 Jesse Keating - rebuilt nss-3.11-2 ---------- * Fri Dec 16 2005 Christopher Aillon 3.11-2 - Update file list for the devel packages openCryptoki-2.1.6-2.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt perl-Archive-Tar-1.26-1.1 ------------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcc perl-Archive-Zip-1.16-1.1 ------------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcc perl-BSD-Resource-1.24-3.1 -------------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj perl-Bit-Vector-6.4-2.1 ----------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj perl-Carp-Clan-5.3-1.1 ---------------------- perl-Compress-Zlib-1.41-1.1 --------------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcc perl-Convert-ASN1-0.19-1.1 -------------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcc perl-Crypt-SSLeay-0.51-9.1 -------------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj perl-DBD-MySQL-3.0002-2.1.1 --------------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcc * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj perl-DBD-Pg-1.43-2.1 -------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj perl-DBI-1.48-4.1 ----------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj perl-Date-Calc-5.4-1.1 ---------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcc perl-DateManip-5.44-1.1 ----------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcc perl-Digest-SHA1-2.10-1.1 ------------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcc perl-File-MMagic-1.22-1.1 ------------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcc perl-HTML-Parser-3.46-1.1 ------------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcc perl-LDAP-1:0.33-1.1 -------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcc perl-Net-DNS-0.53-1.fc5.1 ------------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj perl-PDL-2.4.2-2.fc5.1.1 ------------------------ * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcc * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj perl-TermReadKey-2.30-1.1 ------------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcc perl-XML-Dumper-0.79-1.1 ------------------------ * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcc perl-XML-LibXML-1.58-2.1 ------------------------ * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj * Sat Mar 19 2005 Joe Orton 1.58-2 - rebuild * Sun Apr 18 2004 Ville Skytt?? - 1.58-1 - #121168 - Update to 1.58. - Require perl(:MODULE_COMPAT_*). - Handle ParserDetails.ini parser registration. - BuildRequires libxml2-devel. - Own installed directories. perl-XML-LibXML-Common-0.13-8.1 ------------------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj perl-XML-NamespaceSupport-1.09-1.1 ---------------------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcc perl-XML-Parser-2.34-6.1 ------------------------ * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj perl-XML-Twig-3.17-1.1 ---------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcc perl-libxml-perl-0.08-1.1 ------------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcc pfmon-3.0-6.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt prctl-1.4-5.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt python-2.4.2-2.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt python-elementtree-1.2.6-4.1 ---------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt python-ldap-0:2.0.6-5.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt python-numeric-23.7-2.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt python-sqlite-1.1.6-1.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt qt-1:3.3.5-10.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt quagga-0:0.98.5-3.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt quota-1:3.13-1.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt rarpd-ss981107-22.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt rcs-5.7-29.1 ------------ * Fri Dec 09 2005 Jesse Keating - rebuilt rdate-1.4-4.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt rdesktop-1.4.1-3.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt rdist-1:6.1.5-42.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt readline-5.0-3.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt redhat-lsb-1.3-10.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt redhat-menus-5.0.7-3.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt redhat-rpm-config-8.0.39-1.1 ---------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt reiserfs-utils-2:3.6.19-2.1 --------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt rhn-applet-2.1.17-4.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt rhnlib-2.0-1.p24.3.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt rhpxl-0.8-1.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt rng-utils-1:2.0-1.9.1 --------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj * Fri Dec 09 2005 Jesse Keating - rebuilt rp-pppoe-3.5-30.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt rsh-0.17-33.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt rsync-2.6.6-2.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt rusers-0.17-45.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt rwall-0.17-25.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt rwho-0.17-25.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt salinfo-1:0.5-1.7.1 ------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj samba-0:3.0.20b-2.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt sane-backends-1.0.16-2.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt sane-frontends-1.0.14-1.1 ------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt scim-qtimm-0.9.4-2.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt screen-4.0.2-10.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt scrollkeeper-0.3.14-5.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt sed-4.1.4-1.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt selinux-policy-2.1.6-10 ----------------------- * Fri Dec 16 2005 Dan Walsh 2.1.5-10 - Add enableaudit.pp * Fri Dec 16 2005 Dan Walsh 2.1.5-9 - Fix mls policy sendmail-8.13.5-2.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt setarch-1.8-1.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt setserial-2.17-19.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt setup-2.5.47-1.1.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt * Tue Sep 06 2005 Bill Nottingham 2.5.47-1 - make lastlog 0644 (#167200) * Mon Jun 20 2005 Bill Nottingham 2.5.46-1 - add buildrequires on bash, tcsh (#161016) - move core dump size setting from csh.login to csh.cshrc (#156914) setuptool-1.17.3-1.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt shadow-utils-2:4.0.13-4.1 ------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt shared-mime-info-0.16.cvs20051201-1.2 ------------------------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt sharutils-4.6-2.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt sip-4.3.1-1.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt slib-3a1-5.1 ------------ * Fri Dec 09 2005 Jesse Keating - rebuilt slrn-0.9.8.1pl1-1.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt spamassassin-3.1.0-3.fc5.1 -------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt specspo-9.0.92-1.3.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt speex-1.0.5-1.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt sqlite-3.2.7-2.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt squashfs-tools-2.2r2-2.1 ------------------------ squid-7:2.5.STABLE12-2.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt squirrelmail-1.4.6-0.cvs20050812.2.fc5.1 ---------------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt startup-notification-0.8-3.1 ---------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt statserial-1.1-38.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt strace-4.5.13-1.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt stunnel-4.14-2.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt sudo-1.6.8p12-1.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt swig-1.3.24-2.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt switchdesk-4.0.8-2 ------------------ * Sat Dec 17 2005 Than Ngo 4.0.8-2 - rebuilt symlinks-1.2-24.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt sysfsutils-1.3.0-1.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt syslinux-3.10-2.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt system-config-boot-0.2.11-1.1 ----------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt system-config-cluster-1.0.17-1.0.1 ---------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt system-config-display-1.0.33-1.1 -------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt system-config-httpd-5:1.3.3-1.1 ------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt system-config-keyboard-1.2.7-1.1 -------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt system-config-lvm-1.0.8-1.0.1 ----------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt system-config-netboot-0.1.33-1.1 -------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt system-config-network-1.3.30-2.1 -------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt system-config-packages-1.2.25-1.1 --------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt system-config-printer-0.6.145-1.1 --------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt system-config-rootpassword-1.1.8-1.1 ------------------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt system-config-samba-1.2.31-1.1 ------------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt system-config-securitylevel-1.6.12-1.1 -------------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt system-config-services-0.8.26-1.1 --------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt system-config-soundcard-1.2.14-1.1 ---------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt system-config-users-1.2.41-1.1 ------------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt system-switch-mail-0.5.25-6 --------------------------- * Sat Dec 17 2005 Than Ngo 0.5.25-6 - update po files talk-0.17-29.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt tar-1.15.1-11.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt tcl-8.4.11-1.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt tclx-8.3.5-6.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt tcp_wrappers-7.6-39.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt tcpdump-14:3.9.4-1.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt tcsh-6.14-5.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt telnet-1:0.17-35.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt termcap-1:5.4-7.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt texi2html-1.76-2.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt texinfo-4.8-7.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt tftp-0.41-1.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt time-1.7-27.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt timidity++-2.13.2-1.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt tix-1:8.1.4-100.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt tk-8.4.11-2.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt tmpwatch-2.9.6-1.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt tn5250-0.17.3-1.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt traceroute-2:1.0.3-5.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt tree-1.5.0-3.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt tsclient-0.140-1.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt ttmkfdir-3.0.9-19.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt tux-3.2.18-4.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt tzdata-2005q-2 -------------- * Sat Dec 17 2005 Jakub Jelinek 2005q-2 - 2005q - changes for Georgia, Azerbaijan, Jordan, Palestine, Cuba, Nicaragua - SystemV timezone changes udapl-1.2-0.4265.1.FC5.1 ------------------------ umb-scheme-3.2-39.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt units-1.85-1.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt unix2dos-2.2-26.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt * Wed Apr 13 2005 Tim Waugh - Merge last fix into tmppath patch, which introduced the original problem. unzip-5.51-12.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt up2date-4.4.23-4.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt urw-fonts-2.3-6.1 ----------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj * Thu Nov 17 2005 Warren Togami 2.3-6 - post and postun on reqs usermode-1.84-1.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt utempter-0.5.5-7.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt uucp-1.07-11.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt valgrind-1:3.0.1-2.1 -------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt * Thu Oct 13 2005 Jakub Jelinek 3.0.1-2 - remove Obsoletes for valgrind-callgrind, as it has been ported to valgrind 3.0.x already * Sun Sep 11 2005 Jakub Jelinek 3.0.1-1 - upgrade to 3.0.1 - many bugfixes - handle xattr syscalls on x86-64 (Ulrich Drepper) valgrind-callgrind-0.10.0-1.1 ----------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt vconfig-1.8-7.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt vim-1:6.4.004-1.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt vino-2.12.0-2.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt vlock-1.3-22.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt vnc-4.1.1-30.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt vsftpd-2.0.3-12.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt w3m-0.5.1-12.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt webalizer-2.01_10-29.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt wget-1.10.2-3.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt which-2.16-6.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt wireless-tools-1:28-0.pre10.5.1 ------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt words-3.0-8.1 ------------- * Fri Dec 09 2005 Jesse Keating - rebuilt wordtrans-1.1pre13-12.1 ----------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt wvdial-1.54.0-5.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt x86info-1:1.17-1.18.1 --------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj * Fri Dec 09 2005 Jesse Keating - rebuilt xcdroast-0.98a15-12.1 --------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt xdelta-1.1.3-17.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt xferstats-2.16-13.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt xfsprogs-2.7.3-1.1 ------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt xhtml1-dtds-1.0-7.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt xinetd-2:2.3.13-6.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt xmltex-20020625-6.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt xmlto-0.0.18-9.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt xsane-0.98a-1.1 --------------- * Fri Dec 09 2005 Jesse Keating - rebuilt yp-tools-2.8-8.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt ypbind-3:1.17.2-5.1 ------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt zisofs-tools-1.0.6-3.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt zlib-1.2.3-1.1 -------------- * Fri Dec 09 2005 Jesse Keating - rebuilt Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel = 0:2.6.14-1.1696_FC5 cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5smp cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel = 0:2.6.14-1.1696_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 gnome-python2-libgtop2 - 2.12.1-7.1.i386 requires libgtop-2.0.so.5 jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 systemtap - 0.5-2.i386 requires libdw.so.1(ELFUTILS_0.116) Broken deps for ia64 ---------------------------------------------------------- gnome-python2-libgtop2 - 2.12.1-7.1.ia64 requires libgtop-2.0.so.5()(64bit) jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs systemtap - 0.5-2.ia64 requires libdw.so.1(ELFUTILS_0.116)(64bit) Broken deps for ppc ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 gnome-python2-libgtop2 - 2.12.1-7.1.ppc requires libgtop-2.0.so.5 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 systemtap - 0.5-2.ppc requires libdw.so.1(ELFUTILS_0.116) Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 gnome-python2-libgtop2 - 2.12.1-7.1.ppc64 requires libgtop-2.0.so.5()(64bit) jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) Broken deps for s390 ---------------------------------------------------------- gnome-python2-libgtop2 - 2.12.1-7.1.s390 requires libgtop-2.0.so.5 jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 Broken deps for s390x ---------------------------------------------------------- gnome-python2-libgtop2 - 2.12.1-7.1.s390x requires libgtop-2.0.so.5()(64bit) jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) libgnome-java - 2.12.0-2.s390x requires libgcj.so.6()(64bit) libgnome-java - 2.12.0-2.s390x requires libcairojava-1.0.so()(64bit) libgtk-java - 2.8.0-7.s390x requires libgcj.so.6()(64bit) libvte-java - 0.11.11-6.3.s390x requires libcairojava-1.0.so()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 gnome-python2-libgtop2 - 2.12.1-7.1.x86_64 requires libgtop-2.0.so.5()(64bit) jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) systemtap - 0.5-2.x86_64 requires libdw.so.1(ELFUTILS_0.116)(64bit) From j.w.r.degoede at hhs.nl Sun Dec 18 10:38:45 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 18 Dec 2005 11:38:45 +0100 Subject: yum scriptlet exit status 255 when su-ed to root (with selinux) Message-ID: <43A53C35.9030901@hhs.nl> Hi All, With the latest rawhide I get a lot of: error: %preun(kernel-2.6.13-1.1594_FC5.x86_64) scriptlet failed, exit status 255 error: %pre(kernel-2.6.14-1.1771_FC5.x86_64) scriptlet failed, exit status 255 error: install: %pre scriptlet failed (2), skipping kernel-2.6.14-1.1771_FC5 error: %preun(kernel-2.6.14-1.1770_FC5.x86_64) scriptlet failed, exit status 255 error: %preun(kernel-2.6.14-1.1743_FC5.x86_64) scriptlet failed, exit status 255 error: %preun(kernel-2.6.14-1.1644_FC5.x86_64) scriptlet failed, exit status 255 This is when running yum -y update kernel as root. I became root by doing su - in an xterm started as a normal user. Running yum when directly logged in as root from the console works fine. Bugzilla? Regards, Hans From skn8700 at yahoo.co.in Sun Dec 18 12:38:50 2005 From: skn8700 at yahoo.co.in (SK Sharma) Date: Sun, 18 Dec 2005 12:38:50 +0000 (GMT) Subject: USB drive REformatting -reg Message-ID: <20051218123850.67261.qmail@web8503.mail.in.yahoo.com> Friends, Dunno if this is an appropriate questionon this mail list....I want help to use a PenDrive on ALL linux flavors (if possible on OpenSolaris & WinXX too ?) A friend donated a UNknown format 1GB USB Pendrive and my RH9 Hardware browser detects as a HDD & lists as follows: ============================================================ Drive /dev/sda (Geom: 1022/33/61)(Model: Generic Flash Disk) /dev/sda 1 1 < 1 Free space sda1 1 1023 1005 fat32 ============================================================ How should I interpret the above information,I presume that this is formatted as FAT32, which can be used on Windows. This is enquiring How can I REformat (if required) so that I can use this flash drive on WinXX & Linux file formats as well - please provide step-by-stpe instructions for a novice. thankyou, SKN8700// 18,Dec- Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at redhat.com Sun Dec 18 12:41:31 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Sun, 18 Dec 2005 18:11:31 +0530 Subject: USB drive REformatting -reg In-Reply-To: <20051218123850.67261.qmail@web8503.mail.in.yahoo.com> References: <20051218123850.67261.qmail@web8503.mail.in.yahoo.com> Message-ID: <43A558FB.30201@redhat.com> SK Sharma wrote: > > Friends, > Dunno if this is an appropriate questionon this mail list....I > want > help to use a PenDrive on ALL linux flavors (if possible on > OpenSolaris & > WinXX too ?) http://fedoraproject.org/wiki/PostIsOffTopic regards Rahul From paul at all-the-johnsons.co.uk Sun Dec 18 13:35:13 2005 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Sun, 18 Dec 2005 13:35:13 +0000 Subject: rawhide report: 20051218 changes In-Reply-To: <200512180834.jBI8YatH014352@porkchop.devel.redhat.com> References: <200512180834.jBI8YatH014352@porkchop.devel.redhat.com> Message-ID: <1134912913.3637.14.camel@T7.Linux> Hi, > Broken deps for x86_64 > ---------------------------------------------------------- I keep getting libebook is needed by nautilus-sendto. Is this down to me or is it a packaging problem (libebook is from evolution IIRC) TTFN Paul -- main(t,_,a) char*a;{return!0 References: <43A53C35.9030901@hhs.nl> Message-ID: <604aa7910512180645n3f968eadn73540c96490c3bc0@mail.gmail.com> On 12/18/05, Hans de Goede wrote: > Running yum when directly logged in as root from the console works fine. > > Bugzilla? selinux issue most likely, look over the archives and bugzilla and relabel your filesystem -jef From mihamina.rakotomandimby at etu.univ-orleans.fr Sun Dec 18 16:04:49 2005 From: mihamina.rakotomandimby at etu.univ-orleans.fr (Rakotomandimby Mihamina) Date: Sun, 18 Dec 2005 17:04:49 +0100 Subject: boot faster Message-ID: <1134921889.11021.47.camel@localhost.localdomain> Hi, Here is something that might be interesting: http://www.improvedsource.com/view.php/Linux-System/2/ Why would not Fedora developpers pull some ideas from it to faster and faster the boot time? -- A powerfull GroupWare, CMS, CRM, ECM: CPS (Open Source & GPL). Opengroupware, SPIP, Plone, PhpBB, JetSpeed... are good: CPS is better. http://www.cps-project.org for downloads & documentation. Free hosting of CPS groupware: http://www.objectis.org. From michael.favia at insitesinc.com Sun Dec 18 16:09:59 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Sun, 18 Dec 2005 10:09:59 -0600 Subject: rawhide report: 20051212 changes In-Reply-To: <1134774721.3099.9.camel@localhost.localdomain> References: <200512121122.jBCBMh3T002898@porkchop.devel.redhat.com> <1134774721.3099.9.camel@localhost.localdomain> Message-ID: <43A589D7.5030707@insitesinc.com> Rodd Clarkson wrote: > On Mon, 2005-12-12 at 06:22 -0500, Build System wrote: >> gnome-panel-2.13.2-1.1 >> ---------------------- >> * Fri Dec 09 2005 Jesse Keating >> - rebuilt > > Hmmm, not sure if this is where this problem started, but I think it > might be. > > I'm using transparency in my panels. The Applications/Places/Desktop > menu and the Window Selector applet are now both putting a black > background (with black text) when you have any transparency applied to > the color. > > If I set the color to solid, then they look fine, but apply any > transparency at all and the background turns black and you can't read > the text for these items in the panel. +2 exactly as described but it has been like this for awhile (+2 weeks). -mf From michael.favia at insitesinc.com Sun Dec 18 16:24:47 2005 From: michael.favia at insitesinc.com (Michael Favia) Date: Sun, 18 Dec 2005 10:24:47 -0600 Subject: Azureus (Was: bittorrent in core? what frontend?) In-Reply-To: <43A4C043.5090201@redhat.com> References: <1134662961.28842.128.camel@greebo> <40142.10.10.10.28.1134664763.squirrel@linux1> <1134668805.3312.33.camel@localhost.localdomain> <1134857717.3244.22.camel@localhost.localdomain> <1134870169.13361.23.camel@locolhost.localdomain> <43A4C043.5090201@redhat.com> Message-ID: <43A58D4F.6060401@insitesinc.com> Rahul Sundaram wrote: > Michael A. Peters wrote: > >> On Sat, 2005-12-17 at 14:15 -0800, Anthony Green wrote: >> >> >>> On Thu, 2005-12-15 at 09:46 -0800, Anthony Green wrote: >>> >>>> I will give it another go once a gcj4.1 built SWT (from Eclipse) lands >>>> in rawhide. There have been many Classpath bug fixes over the past >>>> year, so everybody cross your fingers. >>>> >>> Just FYI, I've packaged Azureus for rawhide with our Free stack. Here's >>> a screenshot: >>> >>> http://spindazzle.org/pics/azureus-on-gcj4-2005-12-17.png >>> >> >> That does not look like the ugly java applications I've used :) >> >> >> > It demonstrates the improving maturity of a Free Java platform power by > GCJ. Congrats guys! As well as the elegant hard work done by the Azureus project. I really think this is our bt client. We can default to beginner mode and even disable one of its most important features (UPnP) by default. Those people with routers will know they need to setup port forwarding and will be happy that UPnP is there to greet them. Secure by default, simple for the newcomer and advanced enough to "Just Work" for the power users. -mf From enrico.scholz at informatik.tu-chemnitz.de Sun Dec 18 17:10:06 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Sun, 18 Dec 2005 18:10:06 +0100 Subject: boot faster In-Reply-To: <1134921889.11021.47.camel@localhost.localdomain> (Rakotomandimby Mihamina's message of "Sun, 18 Dec 2005 17:04:49 +0100") References: <1134921889.11021.47.camel@localhost.localdomain> Message-ID: <87irtm5o29.fsf@kosh.bigo.ensc.de> mihamina.rakotomandimby at etu.univ-orleans.fr (Rakotomandimby Mihamina) writes: > Here is something that might be interesting: > http://www.improvedsource.com/view.php/Linux-System/2/ > > Why would not Fedora developpers pull some ideas from it to faster and > faster the boot time? You won't get much improvements when you stay at the old, non-parallel bash-scripts from 'initscripts'. 'initng' is a much better approach and is used by some mainstream distributions (Gentoo, perhaps Debian/Ubuntu) already and Fedora Core developers are positive to the idea to bring it into Fedora Core too. So, it would be better to help to improve it and fix remaining issues (x86_64) in the current FE review[1] Enrico Footnotes: [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173459 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 480 bytes Desc: not available URL: From rdieter at math.unl.edu Sun Dec 18 17:29:25 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Sun, 18 Dec 2005 11:29:25 -0600 Subject: kdebindings-3.5.0-0.1.fc4 pull in ruby In-Reply-To: <1134892535.30243.344.camel@mccallum.corsepiu.local> References: <1134892535.30243.344.camel@mccallum.corsepiu.local> Message-ID: Ralf Corsepius wrote: > The new FC4 kdebindings-3.5.0-0.1.fc4 rpms depend on ruby - Why? kdebindings includes kde bindings for ruby. -- Rex From jspaleta at gmail.com Sun Dec 18 17:40:57 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 18 Dec 2005 12:40:57 -0500 Subject: boot faster In-Reply-To: <1134921889.11021.47.camel@localhost.localdomain> References: <1134921889.11021.47.camel@localhost.localdomain> Message-ID: <604aa7910512180940v3884a78byfc5445eb0e7dbed2@mail.gmail.com> On 12/18/05, Rakotomandimby Mihamina wrote: > Hi, > > Here is something that might be interesting: > http://www.improvedsource.com/view.php/Linux-System/2/ > > Why would not Fedora developpers pull some ideas from it to faster and > faster the boot time? Exactly which ideas do you think are worthwhile for default configurations that Fedora developers should spent some time looking at? I honestly don't see much in the way of generally applicable speed-up ideas. Recompiling of modules into the kernel... which modules are needed to be compiled in is dependant on the system... there is no general solution here that can be applied by default and benefit "most" systems. Tuning which services are running... has no general solution. Whether or not someone needs specific services running is a system by system determination. Turning off auditd and selinux... not going to happen Turning off kudzu completely... not going to happen early-login was under development by Fedora developers, so clearly the Fedora developers have been putting some time thinking about using early-login and have decided its not ready for mainstream use yet. -jef From howe.steven at gmail.com Sun Dec 18 17:52:33 2005 From: howe.steven at gmail.com (Steven Howe) Date: Sun, 18 Dec 2005 09:52:33 -0800 Subject: USB drive REformatting -reg In-Reply-To: <20051218123850.67261.qmail@web8503.mail.in.yahoo.com> References: <20051218123850.67261.qmail@web8503.mail.in.yahoo.com> Message-ID: <1134928353.7890.10.camel@pillage.home> It's ready to use under Win98 and above. YOU DONT need to reformat. Also any speed increase you might expect to see after reformating under ext2 wont be there. USB isn't that fast, nor do they have the large onboard cache that harddisk do. The only issue you might see is the ownership one. Window's disk format does not recognize file ownership. So who ever mount's it owns it. Dismount, mount as a different user and that user will 'own' the files. Onto mounting. command prompt: if a mount point does not exist ... make one mkdir /mnt/flash mount -t vfat /dev/sda1 /mnt/flash # root owns this or add an entry in your /etc/fstab file: /dev/sda1 /mnt/flash auto pamconsole,exec,noauto,managed 0 0 if the hotplug utility worked correctly, then the person on the X-Window Console will own the device /dev/sda1. They a user can mount the device, either through the gui or in a command window (like above). Good luck and Merry Christmas Steven On Sun, 2005-12-18 at 12:38 +0000, SK Sharma wrote: > > Friends, > Dunno if this is an appropriate questionon this mail list....I > want > help to use a PenDrive on ALL linux flavors (if possible on > OpenSolaris & > WinXX too ?) > A friend donated a UNknown format 1GB USB Pendrive and > my RH9 Hardware browser detects as a HDD & lists as follows: > ============================================================ > Drive /dev/sda (Geom: 1022/33/61)(Model: Generic Flash Disk) > /dev/sda > 1 1 < 1 Free space > sda1 1 1023 1005 fat32 > ============================================================ > How should I interpret the above information,I presume ! that > this is formatted as FAT32, which can be used on Windows. > This is enquiring How can I REformat (if required) so that > I can use this flash drive on WinXX & Linux file formats as > well - please provide step-by-stpe instructions for a novice. > > thankyou, > > > SKN8700// > 18,Dec- > > > > Send instant messages to your online friends > http://in.messenger.yahoo.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 j.w.r.degoede at hhs.nl Sun Dec 18 18:16:27 2005 From: j.w.r.degoede at hhs.nl (Hans de Goede) Date: Sun, 18 Dec 2005 19:16:27 +0100 Subject: yum scriptlet exit status 255 when su-ed to root (with selinux) In-Reply-To: <604aa7910512180645n3f968eadn73540c96490c3bc0@mail.gmail.com> References: <43A53C35.9030901@hhs.nl> <604aa7910512180645n3f968eadn73540c96490c3bc0@mail.gmail.com> Message-ID: <43A5A77B.6030105@hhs.nl> Jeff Spaleta wrote: > On 12/18/05, Hans de Goede wrote: >> Running yum when directly logged in as root from the console works fine. >> >> Bugzilla? > > selinux issue most likely, look over the archives and bugzilla and > relabel your filesystem > Filesystem has already been relabeled, both manually and automaticly on reboot, this only happened if I've done "su -" to root, not when directly logged in as root. Regards, Hans From davej at redhat.com Sun Dec 18 21:16:40 2005 From: davej at redhat.com (Dave Jones) Date: Sun, 18 Dec 2005 16:16:40 -0500 Subject: boot faster In-Reply-To: <604aa7910512180940v3884a78byfc5445eb0e7dbed2@mail.gmail.com> References: <1134921889.11021.47.camel@localhost.localdomain> <604aa7910512180940v3884a78byfc5445eb0e7dbed2@mail.gmail.com> Message-ID: <20051218211640.GD10762@redhat.com> On Sun, Dec 18, 2005 at 12:40:57PM -0500, Jeff Spaleta wrote: > Recompiling of modules into the kernel... which modules are needed to > be compiled in is dependant on the system... there is no general > solution here that can be applied by default and benefit "most" > systems. If the modules aren't needed, they also won't be loaded. Any performance gains he saw was likely due to.. "Removed Selinux and auditing system calls feature" although I'm sceptical that was responsible for a 7 second speedup. Dave From jspaleta at gmail.com Sun Dec 18 21:19:03 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sun, 18 Dec 2005 16:19:03 -0500 Subject: boot faster In-Reply-To: <20051218211640.GD10762@redhat.com> References: <1134921889.11021.47.camel@localhost.localdomain> <604aa7910512180940v3884a78byfc5445eb0e7dbed2@mail.gmail.com> <20051218211640.GD10762@redhat.com> Message-ID: <604aa7910512181319q3d6bafd4u148c366958dabec5@mail.gmail.com> On 12/18/05, Dave Jones wrote: > If the modules aren't needed, they also won't be loaded. > Any performance gains he saw was likely due to.. > > "Removed Selinux and auditing system calls feature" > > although I'm sceptical that was responsible for a 7 second speedup. Yes.. the fact that he rolled several changes into one step... irks me. And there was no effort to do repeated runs to get a sense of repeatability of the timed numbers. -jef From dwmw2 at infradead.org Sun Dec 18 21:28:12 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sun, 18 Dec 2005 21:28:12 +0000 Subject: boot faster In-Reply-To: <20051218211640.GD10762@redhat.com> References: <1134921889.11021.47.camel@localhost.localdomain> <604aa7910512180940v3884a78byfc5445eb0e7dbed2@mail.gmail.com> <20051218211640.GD10762@redhat.com> Message-ID: <1134941292.4161.7.camel@pmac.infradead.org> On Sun, 2005-12-18 at 16:16 -0500, Dave Jones wrote: > "Removed Selinux and auditing system calls feature" > > although I'm sceptical that was responsible for a 7 second speedup. Given the current extremely broken default of actually _enabling_ auditing on a rawhide install, 7 seconds wouldn't shock me so much. We really shouldn't be running auditd and enabling syscall auditing on a default install. In fact, I think auditd itself ought to be in Extras if it's in Fedora at all. -- dwmw2 From wrrhdev at riede.org Sun Dec 18 22:30:42 2005 From: wrrhdev at riede.org (Willem Riede) Date: Sun, 18 Dec 2005 22:30:42 +0000 Subject: Problem launching Terminal Message-ID: <1134945042l.19290l.7l@serve.riede.org> After update from today's rawhide I don't seem to be able to launch additional terminals from the gnome menu. "Starting terminal" appears in the panel for several seconds, then disappears. I had two terminals at login after boot from the previously saved session, and those became as dead as a doornail after I had the above experience trying to get a third. Eventually the panel became non-responsive and I had to kill X with ctrl-alt-bs. After logging in again, no more terminals, though the panel problem was not reproducible. After reboot I have my default terminals again... Anybody see anything like this? Thanks, Willem Riede. From denis at poolshark.org Sun Dec 18 22:46:51 2005 From: denis at poolshark.org (Denis Leroy) Date: Sun, 18 Dec 2005 14:46:51 -0800 Subject: Requires vs Requires.private ? Message-ID: <43A5E6DB.5000209@poolshark.org> So what is up with the "Requires.private" entries in various pkgconfig .pc files ? Most mock fc5 builds are currently failing because of a missing dependency between libX11-devel and libxau-devel. Culprit seems to be : bash-3.00# grep -i requires /usr/lib/pkgconfig/x11.pc Requires: xproto kbproto inputproto Requires.private: xau xdmcp From mike at miketc.com Sun Dec 18 23:07:52 2005 From: mike at miketc.com (Mike Chambers) Date: Sun, 18 Dec 2005 17:07:52 -0600 Subject: Problem launching Terminal In-Reply-To: <1134945042l.19290l.7l@serve.riede.org> References: <1134945042l.19290l.7l@serve.riede.org> Message-ID: <1134947272.2483.0.camel@scrappy.miketc.com> On Sun, 2005-12-18 at 22:30 +0000, Willem Riede wrote: > After update from today's rawhide I don't seem to be able to launch additional > terminals from the gnome menu. "Starting terminal" appears in the panel for > several seconds, then disappears. I had two terminals at login after boot from > the previously saved session, and those became as dead as a doornail after I > had the above experience trying to get a third. Eventually the panel became > non-responsive and I had to kill X with ctrl-alt-bs. After logging in again, > no more terminals, though the panel problem was not reproducible. > > After reboot I have my default terminals again... Yep, saw and experiencing the same thing. -- Mike Chambers Madisonville, KY "It's only funny until someone gets hurt, then it's hilarious!" From ellson at research.att.com Sun Dec 18 23:23:25 2005 From: ellson at research.att.com (John Ellson) Date: Sun, 18 Dec 2005 18:23:25 -0500 Subject: Problem launching Terminal In-Reply-To: <1134947272.2483.0.camel@scrappy.miketc.com> References: <1134945042l.19290l.7l@serve.riede.org> <1134947272.2483.0.camel@scrappy.miketc.com> Message-ID: <43A5EF6D.40007@research.att.com> Mike Chambers wrote: > On Sun, 2005-12-18 at 22:30 +0000, Willem Riede wrote: > >> After update from today's rawhide I don't seem to be able to launch additional >> terminals from the gnome menu. "Starting terminal" appears in the panel for >> several seconds, then disappears. I had two terminals at login after boot from >> the previously saved session, and those became as dead as a doornail after I >> had the above experience trying to get a third. Eventually the panel became >> non-responsive and I had to kill X with ctrl-alt-bs. After logging in again, >> no more terminals, though the panel problem was not reproducible. >> >> After reboot I have my default terminals again... >> > > Yep, saw and experiencing the same thing. > > I'm seeing gnome-terminal problems too. I think this has been reported in bug# 176029 John From mpeters at mac.com Mon Dec 19 00:28:46 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 18 Dec 2005 16:28:46 -0800 Subject: Azureus (Was: bittorrent in core? what frontend?) In-Reply-To: <43A58D4F.6060401@insitesinc.com> References: <1134662961.28842.128.camel@greebo> <40142.10.10.10.28.1134664763.squirrel@linux1> <1134668805.3312.33.camel@localhost.localdomain> <1134857717.3244.22.camel@localhost.localdomain> <1134870169.13361.23.camel@locolhost.localdomain> <43A4C043.5090201@redhat.com> <43A58D4F.6060401@insitesinc.com> Message-ID: <1134952126.23129.3.camel@locolhost.localdomain> On Sun, 2005-12-18 at 10:24 -0600, Michael Favia wrote: > We can default to beginner mode and even > disable one of its most important features (UPnP) by default. I don't think that's necessary. If UPnP is a security risk then it should be disabled by the firewall to not allow outgoing UPnP. Disabling it in a userspace doesn't reall do any good because any exploit that would take advantage of it could just simply enable it. Those of us (myself included) who don't want it can disable it at the firewall. Then it doesn't matter what the apps do. From rodd at clarkson.id.au Mon Dec 19 01:27:31 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Mon, 19 Dec 2005 12:27:31 +1100 Subject: rawhide report: 20051218 changes In-Reply-To: <200512180834.jBI8YatH014352@porkchop.devel.redhat.com> References: <200512180834.jBI8YatH014352@porkchop.devel.redhat.com> Message-ID: <1134955651.3350.20.camel@localhost.localdomain> On Sun, 2005-12-18 at 03:34 -0500, Build System wrote: > selinux-policy-2.1.6-10 > ----------------------- > * Fri Dec 16 2005 Dan Walsh 2.1.5-10 > - Add enableaudit.pp > > * Fri Dec 16 2005 Dan Walsh 2.1.5-9 > - Fix mls policy Yum complains: Updating : logrotate ##################### [124/347] Updating : selinux-policy-targeted ##################### [125/347] libsemanage.parse_module_headers: Data did not represent a module. Failed! Updating : tmpwatch ##################### [126/347] Updating : nc ##################### [127/347] -- "It's a fine line between denial and faith. It's much better on my side" From mihamina.rakotomandimby at etu.univ-orleans.fr Mon Dec 19 01:40:07 2005 From: mihamina.rakotomandimby at etu.univ-orleans.fr (Rakotomandimby Mihamina) Date: Mon, 19 Dec 2005 02:40:07 +0100 Subject: boot faster In-Reply-To: <604aa7910512180940v3884a78byfc5445eb0e7dbed2@mail.gmail.com> References: <1134921889.11021.47.camel@localhost.localdomain> <604aa7910512180940v3884a78byfc5445eb0e7dbed2@mail.gmail.com> Message-ID: <1134956408.11021.69.camel@localhost.localdomain> > > Here is something that might be interesting: > > http://www.improvedsource.com/view.php/Linux-System/2/ > Exactly which ideas do you think are worthwhile for default > configurations that Fedora developers should spent some time looking > at? I honestly don't see much in the way of generally applicable > speed-up ideas. I dont really know. I found that document, I just shared what I found... I am not developper, but I use FC4 on my notebook (no dual boot). Booting the fastest would insterest me, and I just brought some ideas... :-) -- A powerfull GroupWare, CMS, CRM, ECM: CPS (Open Source & GPL). Opengroupware, SPIP, Plone, PhpBB, JetSpeed... are good: CPS is better. http://www.cps-project.org for downloads & documentation. Free hosting of CPS groupware: http://www.objectis.org. From mpeters at mac.com Mon Dec 19 02:05:33 2005 From: mpeters at mac.com (Michael A. Peters) Date: Sun, 18 Dec 2005 18:05:33 -0800 Subject: Rhythmbox with iPod support In-Reply-To: <1133679078.5569.18.camel@pluto.jrcormier.com> References: <1133669858.5569.4.camel@pluto.jrcormier.com> <1133670196.3010.5.camel@yoda.loki.me> <1133679078.5569.18.camel@pluto.jrcormier.com> Message-ID: <1134957934.23129.11.camel@locolhost.localdomain> On Sun, 2005-12-04 at 02:51 -0400, Jean-Rene Cormier wrote: > On Sat, 2005-12-03 at 20:23 -0800, Jesse Keating wrote: > > On Sun, 2005-12-04 at 00:17 -0400, Jean-Rene Cormier wrote: > > > > > > I was just wondering if Rhythmbox is gonna have support for iPod in FC5? > > > I just compiled the Rhythmbox SRPMS from rawhide under FC4 and I needed > > > libgpod which is not in rawhide so I'm assuming support for iPod in > > > Rhythmbox won't be in FC5. Is there any reason preventing the inclusion > > > of libgpod in FC? If not I think it would be nice to have it included to > > > get iPod support in Rhythmbox out of the box ;) > > > > > > > Could it be a plugin in extras? > > I haven't seen any options to make a plugin for the different sources > and libgpod is linked to the rhythmbox binary so I don't think a > separate plugin in extras would be possible. I know that people want a > smaller FC but libgpod isn't that big and it would add more > functionality to something that's already in FC. ++ on this request. Currently - I have to export rhythmbox playlists to file. Then run a shell script on files to convert them to .m3u Then launch gtkpod (from livna) to get the playlists onto my iPod. I really would like to be able to see rhythmbox talk directly to my iPod. Yeah yeah - the only audio codec that both Fedora Core and iPod both share in common is wav - but the gstreamer mp3 plugin is easy to get ahold of ... -=-=- What I *really* would prefer though is a common portable device sync library that is not device specific, that can be built to work with many devices - so that rhythmbox (or whatever) could use that library and not care what is on the other end, let the library care. But since that doesn't exist, iPod support would be cool because iPod is what I have :) From rc040203 at freenet.de Mon Dec 19 06:03:31 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 19 Dec 2005 07:03:31 +0100 Subject: kdebindings-3.5.0-0.1.fc4 pull in ruby In-Reply-To: References: <1134892535.30243.344.camel@mccallum.corsepiu.local> Message-ID: <1134972211.12394.19.camel@mccallum.corsepiu.local> On Sun, 2005-12-18 at 11:29 -0600, Rex Dieter wrote: > Ralf Corsepius wrote: > > > The new FC4 kdebindings-3.5.0-0.1.fc4 rpms depend on ruby - Why? > > kdebindings includes kde bindings for ruby. ... then split them off into separate packages, say ruby-kdebindings or similar, as it is done with most other packages. Ralf From tmus at tmus.dk Mon Dec 19 06:02:24 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Mon, 19 Dec 2005 07:02:24 +0100 Subject: Problem launching Terminal In-Reply-To: <43A5EF6D.40007@research.att.com> References: <1134945042l.19290l.7l@serve.riede.org> <1134947272.2483.0.camel@scrappy.miketc.com> <43A5EF6D.40007@research.att.com> Message-ID: John Ellson wrote: > Mike Chambers wrote: >> On Sun, 2005-12-18 at 22:30 +0000, Willem Riede wrote: >> >>> After update from today's rawhide I don't seem to be able to launch >>> additional terminals from the gnome menu. "Starting terminal" >>> appears in the panel for several seconds, then disappears. I had two >>> terminals at login after boot from the previously saved session, and >>> those became as dead as a doornail after I had the above experience >>> trying to get a third. Eventually the panel became non-responsive >>> and I had to kill X with ctrl-alt-bs. After logging in again, no >>> more terminals, though the panel problem was not reproducible. >>> >>> After reboot I have my default terminals again... >>> >> >> Yep, saw and experiencing the same thing. >> >> > I'm seeing gnome-terminal problems too. > > I think this has been reported in bug# 176029 > > John > > Try running gnome-terminal from another terminal (xterm or similar) to perhaps get an idea of what's going on? /Thomas From jkeating at j2solutions.net Mon Dec 19 06:13:34 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 18 Dec 2005 22:13:34 -0800 Subject: kdebindings-3.5.0-0.1.fc4 pull in ruby In-Reply-To: <1134972211.12394.19.camel@mccallum.corsepiu.local> References: <1134892535.30243.344.camel@mccallum.corsepiu.local> <1134972211.12394.19.camel@mccallum.corsepiu.local> Message-ID: <1134972814.3425.5.camel@ender> On Mon, 2005-12-19 at 07:03 +0100, Ralf Corsepius wrote: > ... then split them off into separate packages, say ruby-kdebindings or > similar, as it is done with most other packages. > Sounds like a great task for an enterprising community member. Care to put in the work to make this happen? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From jkeating at j2solutions.net Mon Dec 19 06:31:56 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 18 Dec 2005 22:31:56 -0800 Subject: kdebindings-3.5.0-0.1.fc4 pull in ruby In-Reply-To: <1134972211.12394.19.camel@mccallum.corsepiu.local> References: <1134892535.30243.344.camel@mccallum.corsepiu.local> <1134972211.12394.19.camel@mccallum.corsepiu.local> Message-ID: <1134973916.3425.7.camel@ender> On Mon, 2005-12-19 at 07:03 +0100, Ralf Corsepius wrote: > ... then split them off into separate packages, say ruby-kdebindings or > similar, as it is done with most other packages. > Wait.. kdebindings is a package for non C++ bindings. Why exactly do you want this split into mini sub-packages? The entire package is 5M, really that big of a problem? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From rc040203 at freenet.de Mon Dec 19 06:41:47 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 19 Dec 2005 07:41:47 +0100 Subject: kdebindings-3.5.0-0.1.fc4 pull in ruby In-Reply-To: <1134973916.3425.7.camel@ender> References: <1134892535.30243.344.camel@mccallum.corsepiu.local> <1134972211.12394.19.camel@mccallum.corsepiu.local> <1134973916.3425.7.camel@ender> Message-ID: <1134974507.12394.30.camel@mccallum.corsepiu.local> On Sun, 2005-12-18 at 22:31 -0800, Jesse Keating wrote: > On Mon, 2005-12-19 at 07:03 +0100, Ralf Corsepius wrote: > > ... then split them off into separate packages, say ruby-kdebindings or > > similar, as it is done with most other packages. > > > > Wait.. kdebindings is a package for non C++ bindings. Why exactly do > you want this split into mini sub-packages? The entire package is 5M, > really that big of a problem? No, of cause not - I am worried about the package's working principles and their reflection on packaging. This time it's a more or less unimportant language called ruby adding 5MB, next time it's fortran adding another 5MB, sometime in future it could be java adding 20MB and at some point in future could be C# adding 50 MB. All of them. as a side-effects, pulling in packages an individual user has no use for, and which a add additional security risks. So all this more or less a "beware the beginnings/think twice" concern. Ralf From jkeating at j2solutions.net Mon Dec 19 06:55:40 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Sun, 18 Dec 2005 22:55:40 -0800 Subject: kdebindings-3.5.0-0.1.fc4 pull in ruby In-Reply-To: <1134974507.12394.30.camel@mccallum.corsepiu.local> References: <1134892535.30243.344.camel@mccallum.corsepiu.local> <1134972211.12394.19.camel@mccallum.corsepiu.local> <1134973916.3425.7.camel@ender> <1134974507.12394.30.camel@mccallum.corsepiu.local> Message-ID: <1134975340.3425.11.camel@ender> On Mon, 2005-12-19 at 07:41 +0100, Ralf Corsepius wrote: > No, of cause not - I am worried about the package's working principles > and their reflection on packaging. > > This time it's a more or less unimportant language called ruby adding > 5MB, next time it's fortran adding another 5MB, sometime in future it > could be java adding 20MB and at some point in future could be C# adding > 50 MB. > > All of them. as a side-effects, pulling in packages an individual user > has no use for, and which a add additional security risks. > > So all this more or less a "beware the beginnings/think twice" concern. Ruby itself didn't add 5m. The package includes bindings for ruby, python, and perl, and all the other more generic things necessary to plug these pieces into KDE. So while it can almost make sense to do a kdebindingsbase, then kdebindings-foo for each language, is it really worth the effort right now? -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From alexl at redhat.com Mon Dec 19 08:00:47 2005 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 19 Dec 2005 09:00:47 +0100 Subject: bittorrent in core? what frontend? In-Reply-To: <20051217070856.GD24500@devserv.devel.redhat.com> References: <1134662961.28842.128.camel@greebo> <20051215202126.GA4210@devserv.devel.redhat.com> <1134721846.28842.166.camel@greebo> <20051217070856.GD24500@devserv.devel.redhat.com> Message-ID: <1134979247.28842.210.camel@greebo> On Sat, 2005-12-17 at 02:08 -0500, Bill Nottingham wrote: > Alexander Larsson (alexl at redhat.com) said: > True. It can be packaged around, or just ignored as a problem. It > was just that it seemed to me that having gnome-bt as something > that would pop up after hitting a torrent file in nautilus, firefox, > etc. would be a better solution than the standalone client. I think the standard ui client looks fine for "just clicked on a .torrent file" actually. I'm not sure gnome-bt is better for this. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's an oversexed flyboy jungle king on the hunt for the last specimen of a great and near-mythical creature. She's a cold-hearted snooty politician with a flame-thrower. They fight crime! From alexl at redhat.com Mon Dec 19 08:03:54 2005 From: alexl at redhat.com (Alexander Larsson) Date: Mon, 19 Dec 2005 09:03:54 +0100 Subject: Requires vs Requires.private ? In-Reply-To: <43A5E6DB.5000209@poolshark.org> References: <43A5E6DB.5000209@poolshark.org> Message-ID: <1134979434.28842.214.camel@greebo> On Sun, 2005-12-18 at 14:46 -0800, Denis Leroy wrote: > So what is up with the "Requires.private" entries in various pkgconfig > .pc files ? Most mock fc5 builds are currently failing because of a > missing dependency between libX11-devel and libxau-devel. Culprit seems > to be : > > bash-3.00# grep -i requires /usr/lib/pkgconfig/x11.pc > Requires: xproto kbproto inputproto > Requires.private: xau xdmcp If A Requires.private: B, that means libA links to libB, but apps/libs that link to libA does not have to link to libB (when linking dynamically on platforms that support library dependencies, like Linux). It should not affect -devel packages. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Alexander Larsson Red Hat, Inc alexl at redhat.com alla at lysator.liu.se He's a sword-wielding Catholic farmboy searching for his wife's true killer. She's a wealthy hip-hop archaeologist fleeing from a Satanic cult. They fight crime! From buildsys at redhat.com Mon Dec 19 08:03:00 2005 From: buildsys at redhat.com (Build System) Date: Mon, 19 Dec 2005 03:03:00 -0500 Subject: rawhide report: 20051219 changes Message-ID: <200512190803.jBJ830RO016330@porkchop.devel.redhat.com> Updated Packages: aspell-it-50:0.53-3.1 --------------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj at-3.1.8-80.2 ------------- * Sun Dec 18 2005 Jason Vas Dias - 3.1.8-80.2 - rebuild for new flex * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj * Fri Oct 14 2005 Dan Walsh - 3.1.8-80 - Add seuserbyname support devhelp-0.11-1 -------------- * Sun Dec 18 2005 Ray Strode - 0.11-1 - Update to 0.11 dhcpv6-0.10-15.2 ---------------- * Sun Dec 18 2005 Jason Vas Dias - 0.10-15.2 - rebuild for new gcc & flex dosfstools-2.11-4 ----------------- * Fri Dec 16 2005 Jakub Jelinek 2.11-4 - rebuilt with GCC 4.1 - make it build with -D_FORTIFY_SOURCE=2 flex-2.5.4a-34.3 ---------------- * Sun Dec 18 2005 Jason Vas Dias * rebuild with 'flex-pic.patch' to enable -pie links on x86_64 (patch from Jesse Keating) . gnome-screensaver-0.0.22-2 -------------------------- * Sun Dec 18 2005 Ray Strode - 0.0.22-2 - add floaters screensaver isdn4k-utils-3.2-38 ------------------- * Sun Dec 18 2005 Than Ngo 3.2-38 - add correct app-defaults directory * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj kdeartwork-3.5.0-2 ------------------ * Sat Dec 17 2005 Than Ngo 3.5.0-2 - requires on xscreensaver-extras kernel-2.6.14-1.1773_FC5 ------------------------ * Mon Dec 19 2005 David Woodhouse - Fix thermal overload on liquid-cooled G5s - Fix USB suspend - Disable floppy driver on ppc32 * Sat Dec 17 2005 Dave Jones - 2.6.15-rc5-git7 * Fri Dec 16 2005 David Woodhouse - Update to fixed Cell pause_zero code mgetty-1.1.33-7.FC5 ------------------- * Sun Dec 18 2005 Jason Vas Dias - 1.1.33-7.FC5 - rebuild for new gcc + remove 'xmkmf' invocation for Modular X11 * Fri Dec 09 2005 Jesse Keating - rebuilt nfs-utils-1.0.7-19.FC5.1 ------------------------ * Fri Dec 09 2005 Jesse Keating - rebuilt radvd-0.9-1 ----------- * Mon Dec 18 2006 Jason Vas Dias - Upgrade to upstream version 0.9 * Fri Dec 09 2005 Jesse Keating - rebuilt scim-1.4.2-9 ------------ * Mon Dec 19 2005 Jens Petersen - 1.4.2-9 - enable linker symbol versioning now that mt_alloc is fixed (#173220) - buildrequire libXt-devel for configure - buildrequire autoconf, automake, and libtool for autoreconf xfig-3.2.4-16 ------------- * Sun Dec 18 2005 Than Ngo 3.2.4-16 - add correct app-defaults directory * Fri Dec 09 2005 Jesse Keating - rebuilt xorg-x11-apps-1.0.0-1 --------------------- * Sat Dec 17 2005 Mike A. Harris 1.0.0-1 - Upgraded all apps to version 1.0.0 from X11R7 RC4. - Changed manpage dir from man1x to man1 to match upstream default now. - Dropped all of the datadir-cleanups patches added in the previous build. - Added x11perf-1.0.0-x11perf-datadir-cleanups.patch as it is still needed to put the helper scripts in datadir. - Added --disable-xprint to configure, as a great symbolic jesture. Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp GFS-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel = 0:2.6.14-1.1696_FC5 cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires /lib/modules/2.6.14-1.1696_FC5smp cman-kernel-smp - 2.6.14.0-20051108.134753.FC5.8.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires /lib/modules/2.6.14-1.1696_FC5smp dlm-kernel-smp - 2.6.14.0-20051108.134753.FC5.10.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel = 0:2.6.14-1.1696_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires /lib/modules/2.6.14-1.1696_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.i686 requires kernel-smp = 0:2.6.14-1.1696_FC5 gnome-python2-libgtop2 - 2.12.1-7.1.i386 requires libgtop-2.0.so.5 jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 systemtap - 0.5-2.i386 requires libdw.so.1(ELFUTILS_0.116) Broken deps for ia64 ---------------------------------------------------------- gnome-python2-libgtop2 - 2.12.1-7.1.ia64 requires libgtop-2.0.so.5()(64bit) jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs systemtap - 0.5-2.ia64 requires libdw.so.1(ELFUTILS_0.116)(64bit) Broken deps for ppc ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 gnome-python2-libgtop2 - 2.12.1-7.1.ppc requires libgtop-2.0.so.5 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 systemtap - 0.5-2.ppc requires libdw.so.1(ELFUTILS_0.116) Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 gnome-python2-libgtop2 - 2.12.1-7.1.ppc64 requires libgtop-2.0.so.5()(64bit) jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) Broken deps for s390 ---------------------------------------------------------- gnome-python2-libgtop2 - 2.12.1-7.1.s390 requires libgtop-2.0.so.5 jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 Broken deps for s390x ---------------------------------------------------------- gnome-python2-libgtop2 - 2.12.1-7.1.s390x requires libgtop-2.0.so.5()(64bit) jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) libgnome-java - 2.12.0-2.s390x requires libgcj.so.6()(64bit) libgnome-java - 2.12.0-2.s390x requires libcairojava-1.0.so()(64bit) libgtk-java - 2.8.0-7.s390x requires libgcj.so.6()(64bit) libvte-java - 0.11.11-6.3.s390x requires libcairojava-1.0.so()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 GFS-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 cman-kernel - 2.6.14.0-20051108.134753.FC5.8.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 dlm-kernel - 2.6.14.0-20051108.134753.FC5.10.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires /lib/modules/2.6.14-1.1696_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.x86_64 requires kernel = 0:2.6.14-1.1696_FC5 gnome-python2-libgtop2 - 2.12.1-7.1.x86_64 requires libgtop-2.0.so.5()(64bit) jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) systemtap - 0.5-2.x86_64 requires libdw.so.1(ELFUTILS_0.116)(64bit) From mike at miketc.com Mon Dec 19 08:22:40 2005 From: mike at miketc.com (Mike Chambers) Date: Mon, 19 Dec 2005 02:22:40 -0600 Subject: Problem launching Terminal In-Reply-To: References: <1134945042l.19290l.7l@serve.riede.org> <1134947272.2483.0.camel@scrappy.miketc.com> <43A5EF6D.40007@research.att.com> Message-ID: <1134980560.2941.1.camel@scrappy.miketc.com> On Mon, 2005-12-19 at 07:02 +0100, Thomas M Steenholdt wrote: > Try running gnome-terminal from another terminal (xterm or similar) to > perhaps get an idea of what's going on? Freezes instantly with no error/msg. I switched to VT1 console and logged in (as same user) and did a ps xu and didn't even see the 2nd program running. -- Mike Chambers Madisonville, KY "It's only funny until someone gets hurt, then it's hilarious!" From laroche at redhat.com Mon Dec 19 08:35:42 2005 From: laroche at redhat.com (Florian La Roche) Date: Mon, 19 Dec 2005 09:35:42 +0100 Subject: boot faster In-Reply-To: <1134941292.4161.7.camel@pmac.infradead.org> References: <1134921889.11021.47.camel@localhost.localdomain> <604aa7910512180940v3884a78byfc5445eb0e7dbed2@mail.gmail.com> <20051218211640.GD10762@redhat.com> <1134941292.4161.7.camel@pmac.infradead.org> Message-ID: <20051219083542.GA2954@dudweiler.stuttgart.redhat.com> On Sun, Dec 18, 2005 at 09:28:12PM +0000, David Woodhouse wrote: > On Sun, 2005-12-18 at 16:16 -0500, Dave Jones wrote: > > "Removed Selinux and auditing system calls feature" > > > > although I'm sceptical that was responsible for a 7 second speedup. > > Given the current extremely broken default of actually _enabling_ > auditing on a rawhide install, 7 seconds wouldn't shock me so much. > > We really shouldn't be running auditd and enabling syscall auditing on a > default install. In fact, I think auditd itself ought to be in Extras if > it's in Fedora at all. audit is currently listed within the core packages in comps.xml. Removing it from there should also be possible. Or disabling the startup by default. I still think audit belongs into core. regards, Florian La Roche From enrico.scholz at informatik.tu-chemnitz.de Mon Dec 19 08:39:15 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 19 Dec 2005 09:39:15 +0100 Subject: kdebindings-3.5.0-0.1.fc4 pull in ruby In-Reply-To: <1134975340.3425.11.camel@ender> (Jesse Keating's message of "Sun, 18 Dec 2005 22:55:40 -0800") References: <1134892535.30243.344.camel@mccallum.corsepiu.local> <1134972211.12394.19.camel@mccallum.corsepiu.local> <1134973916.3425.7.camel@ender> <1134974507.12394.30.camel@mccallum.corsepiu.local> <1134975340.3425.11.camel@ender> Message-ID: <87irtlo4zw.fsf@kosh.bigo.ensc.de> jkeating at j2solutions.net (Jesse Keating) writes: >> No, of cause not - I am worried about the package's working principles >> and their reflection on packaging. >> >> So all this more or less a "beware the beginnings/think twice" concern. > > Ruby itself didn't add 5m. The package includes bindings for ruby, > python, and perl, and all the other more generic things necessary to > plug these pieces into KDE. So while it can almost make sense to do a > kdebindingsbase, then kdebindings-foo for each language, is it really > worth the effort right now? I think such a split should be done (not for FC4 but for FC5). Currently, people who need e.g. only ruby bindings are forced to install the huge perl dependency. Unfortunatly, such packaging errors are seen often in Fedora Core. E.g. people who want sendmail are forced to install MySQL and PostgreSQL. Or aspell -- it works perfectly without perl but a packaging bug introduces this huge dependency. Unfortunatly, Fedora Core developers are not sensitive to such bugs and have a "diskspace is cheap" thinking without seeing consequences for security and maintainability of the system. Enrico From fedora at camperquake.de Mon Dec 19 08:49:05 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 19 Dec 2005 09:49:05 +0100 Subject: Using ns_parseerr() on Fedora Devel Message-ID: <20051219084905.GA31712@ryoko.camperquake.de> Hi. I am currently trying to rebuild a recent version of fwbuilder for Fedora Extras and I have hit a wall. The wall is named ns_parserr() and it comes from libresolve, which exists in a static and a dynamic form in /usr/lib. Both seem to be unusable for this function. ns_parserr is replaced by __ns_parserr by the preprocessor. The latter symbol is not present in -lresolv. It is provided, though, by libresolv.a, which fwbuilder thus chooses to link against. This introduces a GLIBC_PRIVATE symbol into the binary (__res_iclose) which RPM does not like at all. So what am I supposed to do against this? Should ns_parserr not be used? Is there a bug in glibc? From seanlkml at sympatico.ca Mon Dec 19 09:17:56 2005 From: seanlkml at sympatico.ca (Sean) Date: Mon, 19 Dec 2005 04:17:56 -0500 (EST) Subject: bittorrent in core? what frontend? In-Reply-To: <1134979247.28842.210.camel@greebo> References: <1134662961.28842.128.camel@greebo> <20051215202126.GA4210@devserv.devel.redhat.com> <1134721846.28842.166.camel@greebo> <20051217070856.GD24500@devserv.devel.redhat.com> <1134979247.28842.210.camel@greebo> Message-ID: On Mon, December 19, 2005 3:00 am, Alexander Larsson said: > > I think the standard ui client looks fine for "just clicked on > a .torrent file" actually. I'm not sure gnome-bt is better for this. > Yeah, the gui looks fine. As for real ease-of-use though it would be nicer if the Fedora client actually supported UPnP. Sean P.S. Just installed the bittorrent-gui to take a look at it and the first thing it says when you start it is "Newer version available, would you like to download it now" which is a bit annoying for a package that should only be updated via rpm. From vonbrand at inf.utfsm.cl Sun Dec 18 16:29:52 2005 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Sun, 18 Dec 2005 13:29:52 -0300 Subject: rawhide report: 20051218 changes In-Reply-To: Message from Build System of "Sun, 18 Dec 2005 03:34:36 CDT." <200512180834.jBI8YatH014352@porkchop.devel.redhat.com> Message-ID: <200512181629.jBIGTq0h023222@laptop11.inf.utfsm.cl> Build System wrote: > Updated Packages: [...] > dmidecode-1:2.6-1.14 > dmidecode-1:2.7-1.22 Why both? -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From fedora at camperquake.de Mon Dec 19 12:19:51 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 19 Dec 2005 13:19:51 +0100 Subject: rawhide report: 20051218 changes In-Reply-To: <200512181629.jBIGTq0h023222@laptop11.inf.utfsm.cl> References: <200512180834.jBI8YatH014352@porkchop.devel.redhat.com> <200512181629.jBIGTq0h023222@laptop11.inf.utfsm.cl> Message-ID: <20051219121951.GB31712@ryoko.camperquake.de> On Sun, Dec 18, 2005 at 01:29:52PM -0300, Horst von Brand wrote: > > dmidecode-1:2.6-1.14 > > dmidecode-1:2.7-1.22 > > Why both? Looks like a hiccup in the build system. From sundaram at redhat.com Mon Dec 19 12:21:20 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 19 Dec 2005 17:51:20 +0530 Subject: boot faster In-Reply-To: <20051219083542.GA2954@dudweiler.stuttgart.redhat.com> References: <1134921889.11021.47.camel@localhost.localdomain> <604aa7910512180940v3884a78byfc5445eb0e7dbed2@mail.gmail.com> <20051218211640.GD10762@redhat.com> <1134941292.4161.7.camel@pmac.infradead.org> <20051219083542.GA2954@dudweiler.stuttgart.redhat.com> Message-ID: <43A6A5C0.1070007@redhat.com> Florian La Roche wrote: >On Sun, Dec 18, 2005 at 09:28:12PM +0000, David Woodhouse wrote: > > >>On Sun, 2005-12-18 at 16:16 -0500, Dave Jones wrote: >> >> >>>"Removed Selinux and auditing system calls feature" >>> >>>although I'm sceptical that was responsible for a 7 second speedup. >>> >>> >>Given the current extremely broken default of actually _enabling_ >>auditing on a rawhide install, 7 seconds wouldn't shock me so much. >> >>We really shouldn't be running auditd and enabling syscall auditing on a >>default install. In fact, I think auditd itself ought to be in Extras if >>it's in Fedora at all. >> >> > >audit is currently listed within the core packages in comps.xml. Removing >it from there should also be possible. Or disabling the startup by default. > >I still think audit belongs into core. > > Maybe but it still needs to be disabled by default if its going to continue having a significant impact on boot up time and general performance. I dont think audit is something Fedora users are interested in general. If we need to iron out wrinkles we can enable it only during the test/development releases. regards Rahul From sundaram at redhat.com Mon Dec 19 12:23:49 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 19 Dec 2005 17:53:49 +0530 Subject: boot faster In-Reply-To: <1134956408.11021.69.camel@localhost.localdomain> References: <1134921889.11021.47.camel@localhost.localdomain> <604aa7910512180940v3884a78byfc5445eb0e7dbed2@mail.gmail.com> <1134956408.11021.69.camel@localhost.localdomain> Message-ID: <43A6A655.6080400@redhat.com> Rakotomandimby Mihamina wrote: >>>Here is something that might be interesting: >>>http://www.improvedsource.com/view.php/Linux-System/2/ >>> >>> >>Exactly which ideas do you think are worthwhile for default >>configurations that Fedora developers should spent some time looking >>at? I honestly don't see much in the way of generally applicable >>speed-up ideas. >> >> > >I dont really know. I found that document, I just shared what I found... >I am not developper, but I use FC4 on my notebook (no dual boot). >Booting the fastest would insterest me, and I just brought some >ideas... :-) > > > Yep. Thank you for your interest. However the above link isnt much useful for that. If you havent noticed yet the whole bootchart program (http://bootchart.sf.net) came out of a challenge in Fedora to reduce boot up time and it did have a good impact on FC4. As others have pointed out this is a ongoing effort. regards Rahul From dennis at ausil.us Mon Dec 19 12:40:56 2005 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 19 Dec 2005 06:40:56 -0600 Subject: kdebindings-3.5.0-0.1.fc4 pull in ruby In-Reply-To: <87irtlo4zw.fsf@kosh.bigo.ensc.de> References: <1134892535.30243.344.camel@mccallum.corsepiu.local> <1134975340.3425.11.camel@ender> <87irtlo4zw.fsf@kosh.bigo.ensc.de> Message-ID: <200512190641.32391.dennis@ausil.us> Once upon a time Monday 19 December 2005 2:39 am, Enrico Scholz wrote: > jkeating at j2solutions.net (Jesse Keating) writes: > >> No, of cause not - I am worried about the package's working principles > >> and their reflection on packaging. > >> > >> So all this more or less a "beware the beginnings/think twice" concern. > > > > Ruby itself didn't add 5m. The package includes bindings for ruby, > > python, and perl, and all the other more generic things necessary to > > plug these pieces into KDE. So while it can almost make sense to do a > > kdebindingsbase, then kdebindings-foo for each language, is it really > > worth the effort right now? Many moons ago Red Hat moved from having all the different apps in there own binary rpms to having 1 rpm per tarball. If we were to now go and split out each and every app into its own binary rpm in one kde package it should be done for every kde package. this would have the effert of greatly increasing the number of rpms in the tree. > I think such a split should be done (not for FC4 but for FC5). Currently, > people who need e.g. only ruby bindings are forced to install the huge > perl dependency. perl its used by many more things > Unfortunatly, such packaging errors are seen often in Fedora > Core. E.g. people who want sendmail are forced to install MySQL and > PostgreSQL. client libs only which i dont think is that bad > Or aspell -- it works perfectly without perl but a packaging bug > introduces this huge dependency. Unfortunatly, Fedora Core developers > are not sensitive to such bugs and have a "diskspace is cheap" thinking > without seeing consequences for security and maintainability of the > system. perl is required by many different packages including X for instance on one of my systems i have [dennis at jaffa ~]$ rpm -q --whatrequires /usr/bin/perl automake15-1.5-13 xplanet-1.1.1-1.1.fc3.fr perl-RPM-Specfile-1.17-2 crossover-standard-3.0.1-1 cedega-4.2ForSteam-1 fbset-2.1-20 autoconf213-2.13-10 jpackage-utils-1.6.3-1jpp_1rh perl-YAML-0.39-2 perltidy-20031021-2 Gtk-Perl-0.7008-38 bonnie++-1.03a-4 ibmonitor-1.3-2 cpan2rpm-2.026-2 perl-XML-Encoding-1.01-27 frozen-bubble-1.0.0-8.2.fc4 perl-IO-stringy-2.110-2 perl-Unicode-Map8-0.12-5 perl-Pod-Coverage-0.17-4.fc4 kino-0.7.6-1.2.fc4 perl-String-ShellQuote-1.03-2 perl-Unicode-Map-0.112-6 perl-XML-XPath-1.13-3 perl-HTML-Tree-3.18-3 perl-Spreadsheet-WriteExcel-2.14-1.fc4 perl-Pod-POM-0.17-4 perl-Image-Size-2.992-3 gtkpod-0.94.0-1.2.fc4 aspell-0.60.3-2 redhat-rpm-config-8.0.39-1 perl-Module-Signature-0.50-1.fc5 perl-Module-Build-0.2611-2.fc5 perl-MIME-Lite-3.01-3.fc5 perl-Module-CoreList-2.02-1.fc5 perl-Net-Server-0.88-1.fc5 patchutils-0.2.31-2 cdlabelgen-3.5.0-1.fc5 gnucash-1.8.11-4 kile-1.8.1-3.fc5 xboard-4.2.7-11.fc5 inkscape-0.42.2-2.fc5 perl-PDL-2.4.2-2.fc5 festival-1.95-4 am-utils-6.1.3-1 perl-GD-2.30-1.fc5 konversation-0.18-5.fc5 fedora-rpmdevtools-1.3-1.fc5 perl-Parse-Yapp-1.05-34.fc5 perl-Net-IP-1.24-2 perl-Archive-Tar-1.26-1 perl-Razor-Agent-2.77-2.fc5 perl-XML-XQL-0.68-1.fc5 glibc-utils-2.3.90-18 sharutils-4.6-2 ghostscript-8.15.1-3 qt-devel-3.3.5-10 w3m-0.5.1-12 xorg-x11-server-Xorg-0.99.3-9 perl-Tk-804.027-8.fc5 glibmm24-devel-2.8.2-1 kdebase-3.5.0-0.2.rc2 xscreensaver-base-4.22-21 ncurses-devel-5.4-22 eclipse-platform-3.1.1-1jpp_9fc kdegraphics-3.5.0-1 kdenetwork-3.5.0-1 perl-5.8.7-8.1 perl-Net-IP-1.24-2.1 libbonobo-2.13.0-1.1 glib2-devel-2.9.1-1 jpackage-utils-1.6.3-1jpp_2rh.1 xorg-x11-font-utils-1.0.0-1 oaf-0.6.10-12.1 psutils-1.17-25.1 netpbm-progs-10.30-2.1 perl-SGMLSpm-1.03ii-16.1 libidn-devel-0.6.0-1.1 lftp-3.3.5-1 perl-Date-Calc-5.4-1.1 numactl-0.6.4-1.24.1 sharutils-4.6-2.1 ncurses-devel-5.4-23.1 automake14-1.4p6-12.1 enscript-1.6.1-31.1 texi2html-1.76-2.1 patchutils-0.2.31-2.1 redhat-rpm-config-8.0.39-1.1 procinfo-18-18.1 valgrind-3.0.1-2.1 fbset-2.1-20.1 autoconf-2.59-5.1 automake-1.9.6-1.1 mod_perl-2.0.2-3.1 perl-DBI-1.48-4.1 mysql-5.0.16-4 perl-libwww-perl-5.803-2.1 docbook-style-xsl-1.69.1-1.1 lm_sensors-2.9.1-5.1 net-snmp-5.2.2-4.1 ethereal-0.10.13-6.1 subversion-1.2.3-6 qt-devel-3.3.5-10.1 cvs-1.11.21-1.1 intltool-0.34.1-1.1 docbook-style-dsssl-1.79-2.1 w3m-0.5.1-12.1 perl-Archive-Tar-1.26-1.1 perl-XML-Twig-3.17-1.1 perl-Archive-Zip-1.16-1.1 perl-PDL-2.4.2-2.fc5.1.1 openldap-servers-2.3.11-3.1 net-snmp-utils-5.2.2-4.1 mysql-server-5.0.16-4 slrn-0.9.8.1pl1-1.1 samba-client-3.0.20b-2.1 automake17-1.7.9-6.1 automake16-1.6.3-5.1 rpm-build-4.4.2-11 ant-scripts-1.6.5-1jpp_1fc.2 stunnel-4.14-2.1 ipv6calc-0.50-1.1 openswan-2.4.4-1.1.1 logwatch-7.1-4.1 a2ps-4.13b-48.1.1 autoconf213-2.13-10.1 kdelibs-3.5.0-3 gstreamer-plugins-0.8.11-1.1 mozilla-1.7.12-3 kdepim-3.5.0-0.1.rc2.1 kdesdk-3.5.0-1.1 bind-9.3.2rc1-1.1 kdemultimedia-3.5.0-1.1 foomatic-3.0.2-29.1 xscreensaver-base-4.22-21.2 docbook-utils-0.6.14-4.1 gtk-doc-1.4-1.1 kdegraphics-3.5.0-2 kdenetwork-3.5.0-1.1 am-utils-6.1.3-1.1 kdevelop-3.3.0-1.1 spamassassin-3.1.0-3.fc5.1 koffice-kpresenter-1.4.2-3.fc5 postfix-2.2.7-1 netatalk-2.0.3-4.1 mc-4.6.1a-5.1 ghostscript-8.15.1-3.1 gnome-utils-2.13.3-1 jessie-1.0.0-10 eclipse-platform-3.1.1-1jpp_10fc -- Dennis Gilmore, RHCE http://www.ausil.us -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From vonbrand at inf.utfsm.cl Mon Dec 19 13:00:55 2005 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Mon, 19 Dec 2005 10:00:55 -0300 Subject: Problem launching Terminal In-Reply-To: Your message of "Mon, 19 Dec 2005 07:02:24 BST." Message-ID: <200512191300.jBJD0tg5025804@laptop11.inf.utfsm.cl> Thomas M Steenholdt wrote: > John Ellson wrote: > > Mike Chambers wrote: > >> On Sun, 2005-12-18 at 22:30 +0000, Willem Riede wrote: > >>> After update from today's rawhide I don't seem to be able to > >>> launch additional terminals from the gnome menu. "Starting > >>> terminal" appears in the panel for several seconds, then > >>> disappears. I had two terminals at login after boot from the > >>> previously saved session, and those became as dead as a doornail > >>> after I had the above experience trying to get a > >>> third. Eventually the panel became non-responsive and I had to > >>> kill X with ctrl-alt-bs. After logging in again, no more > >>> terminals, though the panel problem was not reproducible. > >>> > >>> After reboot I have my default terminals again... > >> Yep, saw and experiencing the same thing. > > I'm seeing gnome-terminal problems too. > > I think this has been reported in bug# 176029 > > John > Try running gnome-terminal from another terminal (xterm or similar) to > perhaps get an idea of what's going on? Same as above: gnome-terminal wouldn't start after updating, running it from an xterm gave no messages or anything. Restarting the X session made no difference. Rebooting cured it for good. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From vonbrand at inf.utfsm.cl Mon Dec 19 13:06:02 2005 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Mon, 19 Dec 2005 10:06:02 -0300 Subject: rawhide report: 20051219 changes In-Reply-To: Your message of "Mon, 19 Dec 2005 03:03:00 CDT." <200512190803.jBJ830RO016330@porkchop.devel.redhat.com> Message-ID: <200512191306.jBJD62HY030508@laptop11.inf.utfsm.cl> Strangely, nmh (in Extras) is at 1.1-15.fc5 both for SRPMS and x86_64, but not for i386. Self-rebuilt for i386, it is what I'm using right now. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From mharris at mharris.ca Mon Dec 19 13:06:46 2005 From: mharris at mharris.ca (Mike A. Harris) Date: Mon, 19 Dec 2005 08:06:46 -0500 Subject: Mesa-6.4.1 now available for Fedora devel Message-ID: <43A6B066.8040807@mharris.ca> Mesa-6.4.1 is now available, which requires libdrm-2.0. Dependencies should be correct for them, however if you have any troubles, make sure you have the two as a pair, as trying to use old libdrm with new mesa or old mesa with new libdrm will not work. There will be a new X11R7 RC4 X server soon, along with all of the RC4 drivers as well. The rest of the RC4 packages not already in rawhide will hopefully all be built today, and end up in tomorrow's rawhide push. -- Mike A. Harris, Open Source Advocate * http://mharris.ca Proud to be Canadian. From rdieter at math.unl.edu Mon Dec 19 13:04:27 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 19 Dec 2005 07:04:27 -0600 Subject: Requires vs Requires.private ? In-Reply-To: <1134979434.28842.214.camel@greebo> References: <43A5E6DB.5000209@poolshark.org> <1134979434.28842.214.camel@greebo> Message-ID: Alexander Larsson wrote: > If A Requires.private: B, that means libA links to libB, but apps/libs > that link to libA does not have to link to libB (when linking > dynamically on platforms that support library dependencies, like Linux). Very nice. Avoids library linking bloat. Too bad libtool archives don't include a "private" feature (at least, AFAIK they don't). -- Rex From rdieter at math.unl.edu Mon Dec 19 13:11:02 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Mon, 19 Dec 2005 07:11:02 -0600 Subject: Requires vs Requires.private ? In-Reply-To: <1134979434.28842.214.camel@greebo> References: <43A5E6DB.5000209@poolshark.org> <1134979434.28842.214.camel@greebo> Message-ID: Alexander Larsson wrote: > If A Requires.private: B, that means libA links to libB, but apps/libs > that link to libA does not have to link to libB (when linking > dynamically on platforms that support library dependencies, like Linux). Very nice. Avoids library linking bloat. Too bad libtool archives don't include a "private" feature (at least, AFAIK they don't). -- Rex From arjan at fenrus.demon.nl Mon Dec 19 13:18:24 2005 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Mon, 19 Dec 2005 14:18:24 +0100 Subject: Requires vs Requires.private ? In-Reply-To: References: <43A5E6DB.5000209@poolshark.org> <1134979434.28842.214.camel@greebo> Message-ID: <1134998305.2947.8.camel@laptopd505.fenrus.org> On Mon, 2005-12-19 at 07:04 -0600, Rex Dieter wrote: > Alexander Larsson wrote: > > > If A Requires.private: B, that means libA links to libB, but apps/libs > > that link to libA does not have to link to libB (when linking > > dynamically on platforms that support library dependencies, like Linux). > > Very nice. Avoids library linking bloat. Too bad libtool archives > don't include a "private" feature (at least, AFAIK they don't).`\ you can achieve the same by giving ld the -Wl,--as-needed flag, then ld will just drop unused linked-to libraries. Unfortunately libtool effectively filters this out as well ;( From mharris at mharris.ca Mon Dec 19 13:19:49 2005 From: mharris at mharris.ca (Mike A. Harris) Date: Mon, 19 Dec 2005 08:19:49 -0500 Subject: Mesa-6.4.1 now available for Fedora devel In-Reply-To: <43A6B066.8040807@mharris.ca> References: <43A6B066.8040807@mharris.ca> Message-ID: <43A6B375.10007@mharris.ca> Mike A. Harris wrote: > Mesa-6.4.1 is now available, which requires libdrm-2.0. Dependencies > should be correct for them, however if you have any troubles, make > sure you have the two as a pair, as trying to use old libdrm with new > mesa or old mesa with new libdrm will not work. > > There will be a new X11R7 RC4 X server soon, along with all of the > RC4 drivers as well. The rest of the RC4 packages not already in > rawhide will hopefully all be built today, and end up in tomorrow's > rawhide push. Duh, and now for the actual URL: ftp://people.redhat.com/mharris/testing/unstable -- Mike A. Harris, Open Source Advocate * http://mharris.ca Proud to be Canadian. From fedora at camperquake.de Mon Dec 19 13:24:09 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 19 Dec 2005 14:24:09 +0100 Subject: Requires vs Requires.private ? In-Reply-To: <1134998305.2947.8.camel@laptopd505.fenrus.org> References: <43A5E6DB.5000209@poolshark.org> <1134979434.28842.214.camel@greebo> <1134998305.2947.8.camel@laptopd505.fenrus.org> Message-ID: <20051219132409.GD31712@ryoko.camperquake.de> On Mon, Dec 19, 2005 at 02:18:24PM +0100, Arjan van de Ven wrote: > you can achieve the same by giving ld the -Wl,--as-needed flag, then ld > will just drop unused linked-to libraries. Unfortunately libtool > effectively filters this out as well ;( I have tried this for a BMP plugin I wrote (it links against all the libraries BMP links against, which is rather a lot), and --as-needed dropped far too much libraries, so I ended up with undefined symbols. From enrico.scholz at informatik.tu-chemnitz.de Mon Dec 19 13:34:21 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Mon, 19 Dec 2005 14:34:21 +0100 Subject: kdebindings-3.5.0-0.1.fc4 pull in ruby In-Reply-To: <200512190641.32391.dennis@ausil.us> (Dennis Gilmore's message of "Mon, 19 Dec 2005 06:40:56 -0600") References: <1134892535.30243.344.camel@mccallum.corsepiu.local> <1134975340.3425.11.camel@ender> <87irtlo4zw.fsf@kosh.bigo.ensc.de> <200512190641.32391.dennis@ausil.us> Message-ID: <87ek49nrc2.fsf@kosh.bigo.ensc.de> dennis at ausil.us (Dennis Gilmore) writes: >> > Ruby itself didn't add 5m. The package includes bindings for ruby, >> > python, and perl, and all the other more generic things necessary to >> > plug these pieces into KDE. So while it can almost make sense to do a >> > kdebindingsbase, then kdebindings-foo for each language, is it really >> > worth the effort right now? > > Many moons ago Red Hat moved from having all the different apps in there own > binary rpms to having 1 rpm per tarball. Not per application. But I would recommend a dependency based splitting. >> I think such a split should be done (not for FC4 but for FC5). Currently, >> people who need e.g. only ruby bindings are forced to install the huge >> perl dependency. > perl its used by many more things sed supports the '-i' switch for some time already, so a big justification for perl does not exist anymore ;) >> Unfortunatly, such packaging errors are seen often in Fedora >> Core. E.g. people who want sendmail are forced to install MySQL and >> PostgreSQL. > client libs only which i dont think is that bad It is bad and does not make sense. >> Or aspell -- it works perfectly without perl but a packaging bug >> introduces this huge dependency. Unfortunatly, Fedora Core developers >> are not sensitive to such bugs and have a "diskspace is cheap" thinking >> without seeing consequences for security and maintainability of the >> system. > perl is required by many different packages including X I just took a look at some real-world productive servers. 12 of them DO NOT need perl, 9 need perl. Here the details: | $ LANG=C vrpm --all -- -e perl perl-Filter | vrpm: operating on vserver backupc | error: package perl is not installed | error: package perl-Filter is not installed | vrpm failed on vserver 'backupc' with errorcode 2 | | vrpm: operating on vserver cheese | error: package perl is not installed | error: package perl-Filter is not installed | vrpm failed on vserver 'cheese' with errorcode 2 | | vrpm: operating on vserver db | error: package perl is not installed | error: package perl-Filter is not installed | vrpm failed on vserver 'db' with errorcode 2 | | vrpm: operating on vserver dhcp | error: package perl is not installed | error: package perl-Filter is not installed | vrpm failed on vserver 'dhcp' with errorcode 2 +4 for NO perl | vrpm: operating on vserver dict | error: Failed dependencies: | /usr/bin/perl is needed by (installed) dict-cgi-0.0.15-1.noarch | vrpm failed on vserver 'dict' with errorcode 2 +1 for perl | vrpm: operating on vserver kerberos | error: package perl is not installed | error: package perl-Filter is not installed | vrpm failed on vserver 'kerberos' with errorcode 2 +1 for NO perl | vrpm: operating on vserver ldap | error: Failed dependencies: | perl is needed by (installed) openssl-perl-0.9.7f-7.10.i386 | /usr/bin/perl is needed by (installed) openssl-perl-0.9.7f-7.10.i386 | /usr/bin/perl is needed by (installed) openldap-servers-2.2.29-1.FC4.i386 | vrpm failed on vserver 'ldap' with errorcode 2 | | vrpm: operating on vserver ldap-master | error: Failed dependencies: | perl is needed by (installed) openssl-perl-0.9.7f-7.10.i386 | /usr/bin/perl is needed by (installed) openssl-perl-0.9.7f-7.10.i386 | /usr/bin/perl is needed by (installed) openldap-servers-2.2.29-1.FC4.i386 | vrpm failed on vserver 'ldap-master' with errorcode 2 openssl-perl is required by my applications perl-dep in openldap-servers is a packaging bug. Migrate scripts should be in an own package. +2 for perl | vrpm: operating on vserver logalyzer | error: package perl is not installed | error: package perl-Filter is not installed | vrpm failed on vserver 'logalyzer' with errorcode 2 neutral, not configured yet | vrpm: operating on vserver mail-filter | error: Failed dependencies: | libperl.so is needed by (installed) mimedefang-2.52-2.i386 | ... | | vrpm: operating on vserver mail-local | error: Failed dependencies: | ... | perl >= 0:5.006_001 is needed by (installed) spamassassin-3.0.4-2.fc4.i386 | ... | | vrpm: operating on vserver mail-www | error: Failed dependencies: | perl(Carp) is needed by (installed) | perl-Cyrus-2.2.12-6.fc4.sigma.i386 | | vrpm: operating on vserver mailbox | error: Failed dependencies: | perl >= 1:5 is needed by (installed) cyrus-imapd-2.2.12-6.fc4.sigma.i386 | ... | | vrpm: operating on vserver news | error: Failed dependencies: | libperl.so is needed by (installed) inn-2.4.2-3.i386 ok, it is really needed here +5 for perl | vrpm: operating on vserver ns | error: package perl is not installed | error: package perl-Filter is not installed | vrpm failed on vserver 'ns' with errorcode 2 +1 for NO perl... | vrpm: operating on vserver svn | error: Failed dependencies: | perl >= 1:5.0 is needed by (installed) subversion-1.2.3-2.1.i386 | ... Packaging bug; %doc files must not add new dependencies +1 for NO perl | vrpm: operating on vserver syslog | error: Failed dependencies: | perl(POSIX) is needed by (installed) stunnel-4.08-2.i386 | /usr/bin/perl is needed by (installed) stunnel-4.08-2.i386 not really needed; the 'stunnel3' backward-compatibility program should be in a separate package or packaged as %doc So, +1 for NO perl | vrpm: operating on vserver twiki | error: Failed dependencies: | perl >= 0:5.005 is needed by (installed) twiki-0.0.20040904-0.i386 +1 for perl | vrpm: operating on vserver vpn | error: Failed dependencies: | /usr/bin/perl is needed by (installed) openvpn-2.0.5-1.fc4.i386 | vrpm failed on vserver 'vpn' with errorcode 2 packaging bug; %doc must not add new deps +1 for NO perl | vrpm: operating on vserver www-cache | error: Failed dependencies: | perl >= 0:5.003 is needed by (installed) squid-2.5.STABLE11-3.FC4.i386 packaging bug; %doc must not add new deps smbauth scripts should be in an own package +1 for NO perl | vrpm: operating on vserver www.XXX.de | error: Failed dependencies: | /usr/bin/perl is needed by (installed) aspell-0.50.5-6.i386 | vrpm failed on vserver 'www.XXX.de' with errorcode 2 | | vrpm: operating on vserver www.YYYYYYYYYY.de | error: Failed dependencies: | /usr/bin/perl is needed by (installed) aspell-0.50.5-6.i386 | vrpm failed on vserver 'www.YYYYYYYYYY.de' with errorcode 2 packaging bug; unneeded program (aspell-import) introduces perl dep +2 for NO perl Enrico From camilo at mesias.co.uk Mon Dec 19 13:42:31 2005 From: camilo at mesias.co.uk (Cam) Date: Mon, 19 Dec 2005 13:42:31 +0000 Subject: booting notebooks vs. suspend (was Re: boot faster) In-Reply-To: <43A6A655.6080400@redhat.com> References: <1134921889.11021.47.camel@localhost.localdomain> <604aa7910512180940v3884a78byfc5445eb0e7dbed2@mail.gmail.com> <1134956408.11021.69.camel@localhost.localdomain> <43A6A655.6080400@redhat.com> Message-ID: <43A6B8C7.5080008@mesias.co.uk> Hi, >> I dont really know. I found that document, I just shared what I found... >> I am not developper, but I use FC4 on my notebook (no dual boot). >> Booting the fastest would insterest me, and I just brought some >> ideas... :-) I'm curious that people would be worried about boot times when it's much faster to suspend and resume. I use a notebook every day but only reboot when there's a new kernel or something has gone badly wrong. Is it the case that released Fedora support for notebook features is lacking? (cf. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=169201) -Cam -- camilo at mesias.co.uk <-- From rc040203 at freenet.de Mon Dec 19 13:49:16 2005 From: rc040203 at freenet.de (Ralf Corsepius) Date: Mon, 19 Dec 2005 14:49:16 +0100 Subject: Mesa-6.4.1 now available for Fedora devel In-Reply-To: <43A6B375.10007@mharris.ca> References: <43A6B066.8040807@mharris.ca> <43A6B375.10007@mharris.ca> Message-ID: <1135000156.12394.52.camel@mccallum.corsepiu.local> On Mon, 2005-12-19 at 08:19 -0500, Mike A. Harris wrote: > Mike A. Harris wrote: > > Mesa-6.4.1 is now available, which requires libdrm-2.0. Dependencies > > should be correct for them, however if you have any troubles, make > > sure you have the two as a pair, as trying to use old libdrm with new > > mesa or old mesa with new libdrm will not work. > > > Duh, and now for the actual URL: > > ftp://people.redhat.com/mharris/testing/unstable None of these PRs seem to have been addressed: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173712 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=173879 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175251 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=175253 Ralf From clydekunkel7734 at cox.net Mon Dec 19 14:10:07 2005 From: clydekunkel7734 at cox.net (Clyde E. Kunkel) Date: Mon, 19 Dec 2005 09:10:07 -0500 Subject: Problem launching Terminal In-Reply-To: <1134945042l.19290l.7l@serve.riede.org> References: <1134945042l.19290l.7l@serve.riede.org> Message-ID: <43A6BF3F.6050500@cox.net> Willem Riede wrote: > After update from today's rawhide I don't seem to be able to launch > additional terminals from the gnome menu. "Starting terminal" appears in > the panel for several seconds, then disappears. I had two terminals at > login after boot from the previously saved session, and those became as > dead as a doornail after I had the above experience trying to get a > third. Eventually the panel became non-responsive and I had to kill X > with ctrl-alt-bs. After logging in again, no more terminals, though the > panel problem was not reproducible. > > After reboot I have my default terminals again... > > Anybody see anything like this? > > Thanks, Willem Riede. > > --fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > Add gnome-terminal to the menu bar and remove the parameter passed to it. -- Regards, Old Fart From dennis at ausil.us Mon Dec 19 14:46:19 2005 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 19 Dec 2005 08:46:19 -0600 Subject: dbus-qt bindings Message-ID: <200512190846.19710.dennis@ausil.us> hey all I filed as RFE in bug #176106 that dbus-qt be re-enabled Id like to have re-enabled the dbus bindings for qt the updated bindings for qt4 have been back ported for qt3 see http://www.kdedevelopers.org/node/1687 i would ask that anyone interested in seeing this go in please make a comment in the bug to show support and interest Regards Dennis From drepper at redhat.com Mon Dec 19 15:24:18 2005 From: drepper at redhat.com (Ulrich Drepper) Date: Mon, 19 Dec 2005 07:24:18 -0800 Subject: Using ns_parseerr() on Fedora Devel In-Reply-To: <20051219084905.GA31712@ryoko.camperquake.de> References: <20051219084905.GA31712@ryoko.camperquake.de> Message-ID: <43A6D0A2.2080901@redhat.com> Ralf Ertzinger wrote: > So what am I supposed to do against this? Should ns_parserr not be > used? Correct. Every symbol which is not exported from the DSOs or exported with version GLIBC_PRIVATE are, shockingly, *private*. They might go away, their semantics can change, whatever. There is no way to prevent such exports from .a files so they are available there but this does not mean they should be used. -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? From ph18 at cornell.edu Mon Dec 19 15:42:28 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Mon, 19 Dec 2005 10:42:28 -0500 Subject: bittorrent in core? what frontend? In-Reply-To: <1134834793.13361.3.camel@locolhost.localdomain> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> <1134822155.10233.6.camel@locolhost.localdomain> <41673.10.10.10.28.1134823273.squirrel@linux1> <1134834793.13361.3.camel@locolhost.localdomain> Message-ID: <43A6D4E4.9070001@cornell.edu> Michael A. Peters wrote: > Oh I see what you are saying. > When trusted application foo is being run by user in trusted group bar > (or open for any user) - the firewall will open ports xxxx to yyyy > should foo request they be opened - for the duration that foo is > running. > > That would be slick. > > Overall, that kind of thinking is what it's going to take to use SELinux to get real security improvements over standard Linux for processes that are run by everyday users... We'll need some kind of "security manager" where root can tick off what kind of actions that root wants to allow ordinary users to do. From ph18 at cornell.edu Mon Dec 19 15:50:29 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Mon, 19 Dec 2005 10:50:29 -0500 Subject: bittorrent in core? what frontend? In-Reply-To: <1134847663.24472.82.camel@yoda.loki.me> References: <1134662961.28842.128.camel@greebo> <43A195D3.2090302@city-fan.org> <20051215164216.GB9717@tomservo.boston.redhat.com> <43A19DAF.6050407@insitesinc.com> <1134671012.12010.134.camel@remedyz.boston.redhat.com> <604aa7910512151033v9efc510w733bb790ce8c8@mail.gmail.com> <43A36275.40609@redhat.com> <1134809603.3032.28.camel@locolhost.localdomain> <39507.10.10.10.28.1134812757.squirrel@linux1> <1134846931.24472.78.camel@yoda.loki.me> <35487.10.10.10.28.1134847155.squirrel@linux1> <1134847663.24472.82.camel@yoda.loki.me> Message-ID: <43A6D6C5.6000802@cornell.edu> Jesse Keating wrote: > I'm sorry that BT is so difficult to use that you have to futz with > firewalls. But I don't feel that it is Fedora's place to allow > applications to poke holes in firewalls not even on the system. > It's not just a question about BT, but rather a question about what direction the internet is going. IPV6 adoption looks stalled, and on some days it seems that it will never happen. (Are ~you~ going to put ~your~ web server on an IP address that 1% of the world to see?) One immediate answer to the IP shortage is NAT, which works fine with certain sorts of protocols (http) but has made other protocols (ftp) obsolete or unworkable. If NAT's a fact of life, we ought to start thinking about how to make our software work in the new age. CPAN, for instance, is a piece of software that "just doesn't work" in internet 2005 because of ftp dependence-- most of the machines I run it on have some serious issues with firewalls, which can sometimes be worked around by setting some obscure settings to enable passive mode, and sometimes requires work on the machine-level firewall and sometimes the corporate firewall. My home network is designed entirely around the needs of devices that "just work" -- the assumption is that people are going to use PDA's and internet tablets, and that you can plug in something like an Xbox360 or an internet stereo. For any problems it may have, UPnP is a part of making that possible -- of making internet a mainstream phenomenon, not just something for geeks. From fedora at camperquake.de Mon Dec 19 15:57:31 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 19 Dec 2005 16:57:31 +0100 Subject: Using ns_parseerr() on Fedora Devel In-Reply-To: <43A6D0A2.2080901@redhat.com> References: <20051219084905.GA31712@ryoko.camperquake.de> <43A6D0A2.2080901@redhat.com> Message-ID: <20051219155731.GF31712@ryoko.camperquake.de> On Mon, Dec 19, 2005 at 07:24:18AM -0800, Ulrich Drepper wrote: > Correct. Every symbol which is not exported from the DSOs or exported > with version GLIBC_PRIVATE are, shockingly, *private*. But ns_parserr is not private. It is defined if you include . > away, their semantics can change, whatever. There is no way to prevent > such exports from .a files so they are available there but this does not > mean they should be used. Any suggestions as what the official replacement for ns_parserr is? From davej at redhat.com Mon Dec 19 16:01:44 2005 From: davej at redhat.com (Dave Jones) Date: Mon, 19 Dec 2005 11:01:44 -0500 Subject: boot faster In-Reply-To: <43A6A5C0.1070007@redhat.com> References: <1134921889.11021.47.camel@localhost.localdomain> <604aa7910512180940v3884a78byfc5445eb0e7dbed2@mail.gmail.com> <20051218211640.GD10762@redhat.com> <1134941292.4161.7.camel@pmac.infradead.org> <20051219083542.GA2954@dudweiler.stuttgart.redhat.com> <43A6A5C0.1070007@redhat.com> Message-ID: <20051219160144.GB19568@redhat.com> On Mon, Dec 19, 2005 at 05:51:20PM +0530, Rahul Sundaram wrote: > >audit is currently listed within the core packages in comps.xml. Removing > >it from there should also be possible. Or disabling the startup by default. > > > >I still think audit belongs into core. > > > Maybe but it still needs to be disabled by default if its going to > continue having a significant impact on boot up time and general > performance. I dont think audit is something Fedora users are interested > in general. If we need to iron out wrinkles we can enable it only during > the test/development releases. audit has the potential to be useful though. It could be used to dynamically generate readahead.files Addition of extra services would need nothing to be changed, they'd get picked up on next boot, and added to the filelist, for speeding up subsequent boots. Dave From jkeating at j2solutions.net Mon Dec 19 16:05:39 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 19 Dec 2005 08:05:39 -0800 Subject: booting notebooks vs. suspend (was Re: boot faster) In-Reply-To: <43A6B8C7.5080008@mesias.co.uk> References: <1134921889.11021.47.camel@localhost.localdomain> <604aa7910512180940v3884a78byfc5445eb0e7dbed2@mail.gmail.com> <1134956408.11021.69.camel@localhost.localdomain> <43A6A655.6080400@redhat.com> <43A6B8C7.5080008@mesias.co.uk> Message-ID: <1135008339.28062.0.camel@yoda.loki.me> On Mon, 2005-12-19 at 13:42 +0000, Cam wrote: > > I'm curious that people would be worried about boot times when it's much > faster to suspend and resume. I use a notebook every day but only reboot > when there's a new kernel or something has gone badly wrong. Swapping batteries. Rebooting into another OS. Booting to a new kernel. There are many reasons why a full boot will be done. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From sundaram at redhat.com Mon Dec 19 16:09:05 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Mon, 19 Dec 2005 21:39:05 +0530 Subject: boot faster In-Reply-To: <20051219160144.GB19568@redhat.com> References: <1134921889.11021.47.camel@localhost.localdomain> <604aa7910512180940v3884a78byfc5445eb0e7dbed2@mail.gmail.com> <20051218211640.GD10762@redhat.com> <1134941292.4161.7.camel@pmac.infradead.org> <20051219083542.GA2954@dudweiler.stuttgart.redhat.com> <43A6A5C0.1070007@redhat.com> <20051219160144.GB19568@redhat.com> Message-ID: <43A6DB21.9010600@redhat.com> Dave Jones wrote: >On Mon, Dec 19, 2005 at 05:51:20PM +0530, Rahul Sundaram wrote: > > > >audit is currently listed within the core packages in comps.xml. Removing > > >it from there should also be possible. Or disabling the startup by default. > > > > > >I still think audit belongs into core. > > > > > Maybe but it still needs to be disabled by default if its going to > > continue having a significant impact on boot up time and general > > performance. I dont think audit is something Fedora users are interested > > in general. If we need to iron out wrinkles we can enable it only during > > the test/development releases. > >audit has the potential to be useful though. It could be used to >dynamically generate readahead.files Addition of extra services >would need nothing to be changed, they'd get picked up on next boot, >and added to the filelist, for speeding up subsequent boots. > > > Have you looked at preload ( http://fedoraproject.org/wiki/FedoraBounties)? regards Rahul From gilboad at gmail.com Mon Dec 19 16:13:27 2005 From: gilboad at gmail.com (Gilboa Davara) Date: Mon, 19 Dec 2005 18:13:27 +0200 Subject: booting notebooks vs. suspend (was Re: boot faster) In-Reply-To: <1135008339.28062.0.camel@yoda.loki.me> References: <1134921889.11021.47.camel@localhost.localdomain> <604aa7910512180940v3884a78byfc5445eb0e7dbed2@mail.gmail.com> <1134956408.11021.69.camel@localhost.localdomain> <43A6A655.6080400@redhat.com> <43A6B8C7.5080008@mesias.co.uk> <1135008339.28062.0.camel@yoda.loki.me> Message-ID: <1135008807.14566.38.camel@gilboa-work-dev> On Mon, 2005-12-19 at 08:05 -0800, Jesse Keating wrote: > On Mon, 2005-12-19 at 13:42 +0000, Cam wrote: > > > > I'm curious that people would be worried about boot times when it's much > > faster to suspend and resume. I use a notebook every day but only reboot > > when there's a new kernel or something has gone badly wrong. > > Swapping batteries. Rebooting into another OS. Booting to a new > kernel. > > There are many reasons why a full boot will be done. > > -- Umm... I rarely boot my machines (once in a couple of months), but I'd venture to guess that if suspend-resume was bullet-proof, people would have rebooted their machine only in the cases above, which are pretty rare events for most Linux users. Plus, I might be wrong here, but doesn't suspend to disk theoretically allows you to suspend, switch to Windows (*spit!), and pick up where you left once you switch back to Linux? Gilboa From fedora at camperquake.de Mon Dec 19 16:21:03 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 19 Dec 2005 17:21:03 +0100 Subject: booting notebooks vs. suspend (was Re: boot faster) In-Reply-To: <1135008807.14566.38.camel@gilboa-work-dev> References: <1134921889.11021.47.camel@localhost.localdomain> <604aa7910512180940v3884a78byfc5445eb0e7dbed2@mail.gmail.com> <1134956408.11021.69.camel@localhost.localdomain> <43A6A655.6080400@redhat.com> <43A6B8C7.5080008@mesias.co.uk> <1135008339.28062.0.camel@yoda.loki.me> <1135008807.14566.38.camel@gilboa-work-dev> Message-ID: <20051219162103.GG31712@ryoko.camperquake.de> On Mon, Dec 19, 2005 at 06:13:27PM +0200, Gilboa Davara wrote: > Umm... I rarely boot my machines (once in a couple of months), but I'd > venture to guess that if suspend-resume was bullet-proof, people would > have rebooted their machine only in the cases above, which are pretty > rare events for most Linux users. > Plus, I might be wrong here, but doesn't suspend to disk theoretically > allows you to suspend, switch to Windows (*spit!), and pick up where you > left once you switch back to Linux? As long as windows leaves the Linux partitions alone that should work. From johnp at redhat.com Mon Dec 19 16:30:50 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Mon, 19 Dec 2005 11:30:50 -0500 Subject: dbus-qt bindings In-Reply-To: <200512190846.19710.dennis@ausil.us> References: <200512190846.19710.dennis@ausil.us> Message-ID: <1135009850.2066.44.camel@remedyz.boston.redhat.com> On Mon, 2005-12-19 at 08:46 -0600, Dennis Gilmore wrote: > hey all > > I filed as RFE in bug #176106 that dbus-qt be re-enabled > > Id like to have re-enabled the dbus bindings for qt the updated bindings for > qt4 have been back ported for qt3 see http://www.kdedevelopers.org/node/1687 > i would ask that anyone interested in seeing this go in please make a comment > in the bug to show support and interest > I would ask people not to do this. I already understand there is huge interest and am working with the upstream developer to find out the status and where he thinks things are with the bindings. They are not upstream yet and they are in heavy flux. I'm not sure if KDE even uses them yet. Spamming the bug just fills my inbox and is of no help. Thanks. -- John (J5) Palmieri From johnp at redhat.com Mon Dec 19 16:40:55 2005 From: johnp at redhat.com (John (J5) Palmieri) Date: Mon, 19 Dec 2005 11:40:55 -0500 Subject: dbus-qt bindings In-Reply-To: <1135009850.2066.44.camel@remedyz.boston.redhat.com> References: <200512190846.19710.dennis@ausil.us> <1135009850.2066.44.camel@remedyz.boston.redhat.com> Message-ID: <1135010455.2066.52.camel@remedyz.boston.redhat.com> As I was told KDE 3.5 does not use these bindings and KDE will not be making another major release until 4.0 (correct me if I am wrong) so the chances of anything getting rebased to the new bindings is very slim. I stand by my thoughts that all the functionality that KDE uses (which is slim, mostly just talking to HAL) should just be rolled into IOSlave or whatever uses it and a point release made. This was actually the suggestion that the Qt4 binding maintainer made awhile ago. On Mon, 2005-12-19 at 11:30 -0500, John (J5) Palmieri wrote: > On Mon, 2005-12-19 at 08:46 -0600, Dennis Gilmore wrote: > > hey all > > > > I filed as RFE in bug #176106 that dbus-qt be re-enabled > > > > Id like to have re-enabled the dbus bindings for qt the updated bindings for > > qt4 have been back ported for qt3 see http://www.kdedevelopers.org/node/1687 > > i would ask that anyone interested in seeing this go in please make a comment > > in the bug to show support and interest > > > I would ask people not to do this. I already understand there is huge > interest and am working with the upstream developer to find out the > status and where he thinks things are with the bindings. They are not > upstream yet and they are in heavy flux. I'm not sure if KDE even uses > them yet. Spamming the bug just fills my inbox and is of no help. > Thanks. > > -- > John (J5) Palmieri -- John (J5) Palmieri From notting at redhat.com Mon Dec 19 16:40:58 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Dec 2005 11:40:58 -0500 Subject: libusual interface [was Re: libusual and ub] In-Reply-To: <20051217013313.3da8bfa2.zaitcev@redhat.com> References: <20051215031822.GA12020@devserv.devel.redhat.com> <20051214211008.22c1ae47.zaitcev@redhat.com> <20051215053741.GA13787@devserv.devel.redhat.com> <20051215002129.4e9863e0.zaitcev@redhat.com> <1134655233.2864.31.camel@bree.local.net> <20051216001243.446d94e3.zaitcev@redhat.com> <20051217065304.GA24500@devserv.devel.redhat.com> <20051216231839.7c4bc38a.zaitcev@redhat.com> <20051217072150.GG24500@devserv.devel.redhat.com> <20051217013313.3da8bfa2.zaitcev@redhat.com> Message-ID: <20051219164058.GC12747@devserv.devel.redhat.com> Pete Zaitcev (zaitcev at redhat.com) said: > On Sat, 17 Dec 2005 02:21:50 -0500, Bill Nottingham wrote: > > > I mean separate the aliases *into the base drivers themselves* - not > > using libusual at all. i.e., a given usb id only matches one of > > usb-storage or ub. > > Nothing new in this approach either. This is how ub worked way before > libusual, and before Adrian Bunk broke it. The problem is, users require > a capability to switch between drivers. And we cannot predict which one > they want to use for any given device. *Why* do they need the capability? Users *should not care* which driver they use - if they do, one of them needs fixed. Bill From darrellpf at gmail.com Mon Dec 19 16:47:09 2005 From: darrellpf at gmail.com (darrell pfeifer) Date: Mon, 19 Dec 2005 08:47:09 -0800 Subject: unicode characters Message-ID: I am running the latest rawhide. Sometime in the last several days some of my unicode characters have started appearing as the "unrecognized" empty square (I don't know what it is officially called). This is true for www.chinesepod.com, which is mostly in English but has a few Chinese symbols. It is also happens in Eclipse with Java source code, mostly before and after the double quote character. I'm using the non-gcj version of Eclipse. The file appears normally using kwrite. My language settings have been UTF-8 for a long time. I've seen this happen once before and it seemed to correct itself with font updates. Any suggestions on where to look? thanks darrell From paul at city-fan.org Mon Dec 19 16:52:45 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 19 Dec 2005 16:52:45 +0000 Subject: bittorrent in core? what frontend? In-Reply-To: References: <1134662961.28842.128.camel@greebo> <20051215202126.GA4210@devserv.devel.redhat.com> <1134721846.28842.166.camel@greebo> <20051217070856.GD24500@devserv.devel.redhat.com> <1134979247.28842.210.camel@greebo> Message-ID: <43A6E55D.9070303@city-fan.org> Sean wrote: > On Mon, December 19, 2005 3:00 am, Alexander Larsson said: > > >>I think the standard ui client looks fine for "just clicked on >>a .torrent file" actually. I'm not sure gnome-bt is better for this. >> > > > Yeah, the gui looks fine. As for real ease-of-use though it would be > nicer if the Fedora client actually supported UPnP. > > Sean > > P.S. Just installed the bittorrent-gui to take a look at it and the first > thing it says when you start it is "Newer version available, would you > like to download it now" which is a bit annoying for a package that should > only be updated via rpm. I've pushed an update to 4.2.2 earlier today. I'm not sure about disabling the "updated version" check. On the one hand people should only be updating the package using RPM, but on the other hand the alert will let them know that a new version is available, and that might prompt them to run "yum update" if they don't have automatic updates turned on. Paul. From dennis at ausil.us Mon Dec 19 17:13:22 2005 From: dennis at ausil.us (Dennis Gilmore) Date: Mon, 19 Dec 2005 11:13:22 -0600 Subject: dbus-qt bindings In-Reply-To: <1135010455.2066.52.camel@remedyz.boston.redhat.com> References: <200512190846.19710.dennis@ausil.us> <1135009850.2066.44.camel@remedyz.boston.redhat.com> <1135010455.2066.52.camel@remedyz.boston.redhat.com> Message-ID: <200512191113.25304.dennis@ausil.us> On Monday 19 December 2005 10:40, John (J5) Palmieri wrote: > As I was told KDE 3.5 does not use these bindings and KDE will not be > making another major release until 4.0 (correct me if I am wrong) so the > chances of anything getting rebased to the new bindings is very slim. I > stand by my thoughts that all the functionality that KDE uses (which is > slim, mostly just talking to HAL) should just be rolled into IOSlave or > whatever uses it and a point release made. This was actually the > suggestion that the Qt4 binding maintainer made awhile ago. OK, when we had dbus-qt if i plugged in a usb drive i was prompted to mount the drive or ignore it etc. this does not work now that the support has been removed. so what was there while not perfect and not being maintained worked. but now there is nothing. i plug something it i need to go mount it by hand. when i saw that there was some newer bindings i saw it as an opportunity to get things back in. I believe the next major release of kde will be 4.0 I guess its time to brush up on C++ Dennis From jkeating at redhat.com Mon Dec 19 17:14:42 2005 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 Dec 2005 09:14:42 -0800 Subject: Fedora Core 5 Test 2 slipping until January 16 Message-ID: <1135012482.28062.26.camel@yoda.loki.me> Dashing through the builds In a one cup holder desk O're the build errors we go Swearing all the way! Phones on dev's desks ring Making Managers frown What fun it is to cuss and swear re-baseing on GCC! Oh, software sucks, Software sucks, Software really sucks! Oh what fun it is to slip our release for a month! Software sucks, Software sucks, Software really sucks! Oh, what fun it is to slip our release for a month! We rebuilt java* once It wasn't very nice we rebuilt everything else to our user's delight! Broken deps still there Making testing fun We really thing we need to test for another month! Oh, software sucks, Software sucks, Software really sucks! Oh what fun it is to slip our release for a month! Oh What Fun It Is To Slip Our Release For A Monnnnnnnnnnnnnnnnth!!! Ok, it won't be a full month, but due to the recent upgrade of gcc and the subsequent full rebuild of everything that does (and doesn't, whoops!) get built with gcc, including java stuff with gcj, and the need to further test package selection windows in Anaconda, system-config-packages for upgrades, and the development tree in general once we settle down the rebuilds, we have decided to delay test2. Here is a new schedule that we will be working toward: * Test2 freeze date to 9 January * Test2 release, 16 January * Test3 freeze, 6 February * Test3 release, 13 February * Final absolute freeze, 6 March * Release, 15 March We are going to try very hard to have a stable(ish) tree suitable for testing over the holidays, so that Test2 will be better for the slip and keep us in line with getting Test3 and eventually the final release out in the best shape possible. Thank you all for your hard work in helping us develop the best distribution we can! -- Jesse Keating Release Engineer: Fedora From arjan at fenrus.demon.nl Mon Dec 19 17:17:38 2005 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Mon, 19 Dec 2005 18:17:38 +0100 Subject: Fedora Core 5 Test 2 slipping until January 16 In-Reply-To: <1135012482.28062.26.camel@yoda.loki.me> References: <1135012482.28062.26.camel@yoda.loki.me> Message-ID: <1135012659.2947.13.camel@laptopd505.fenrus.org> On Mon, 2005-12-19 at 09:14 -0800, Jesse Keating wrote: > Ok, it won't be a full month, but due to the recent upgrade of gcc and does this mean that the handoff of FC3 to fedora legacy is also delayed a month ? From roozbeh at farsiweb.info Mon Dec 19 17:18:05 2005 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Mon, 19 Dec 2005 20:48:05 +0330 Subject: bittorrent in core? what frontend? In-Reply-To: <43A6E55D.9070303@city-fan.org> References: <1134662961.28842.128.camel@greebo> <20051215202126.GA4210@devserv.devel.redhat.com> <1134721846.28842.166.camel@greebo> <20051217070856.GD24500@devserv.devel.redhat.com> <1134979247.28842.210.camel@greebo> <43A6E55D.9070303@city-fan.org> Message-ID: <1135012685.2976.21.camel@tameshk.bamdad.org> On Mon, 2005-12-19 at 16:52 +0000, Paul Howarth wrote: > [...] but on the other hand the alert > will let them know that a new version is available, and that might > prompt them to run "yum update" if they don't have automatic updates > turned on. But on the yet other hand the update may not be available in the yum repository yet (and may not even be there six months later if it's not an important update), which will simply frustrate them. roozbeh From wtogami at redhat.com Mon Dec 19 17:21:53 2005 From: wtogami at redhat.com (Warren Togami) Date: Mon, 19 Dec 2005 12:21:53 -0500 Subject: Fedora Core 5 Test 2 slipping until January 16 In-Reply-To: <1135012659.2947.13.camel@laptopd505.fenrus.org> References: <1135012482.28062.26.camel@yoda.loki.me> <1135012659.2947.13.camel@laptopd505.fenrus.org> Message-ID: <43A6EC31.3000603@redhat.com> Arjan van de Ven wrote: > On Mon, 2005-12-19 at 09:14 -0800, Jesse Keating wrote: > >> Ok, it won't be a full month, but due to the recent upgrade of gcc and > > > does this mean that the handoff of FC3 to fedora legacy is also delayed > a month ? Whenever test2 is released, FC3 maintainership will be handed to Legacy. Warren Togami wtogami at redhat.com From jkeating at redhat.com Mon Dec 19 17:23:23 2005 From: jkeating at redhat.com (Jesse Keating) Date: Mon, 19 Dec 2005 09:23:23 -0800 Subject: Fedora Core 5 Test 2 slipping until January 16 In-Reply-To: <1135012659.2947.13.camel@laptopd505.fenrus.org> References: <1135012482.28062.26.camel@yoda.loki.me> <1135012659.2947.13.camel@laptopd505.fenrus.org> Message-ID: <1135013003.28062.32.camel@yoda.loki.me> On Mon, 2005-12-19 at 18:17 +0100, Arjan van de Ven wrote: > > does this mean that the handoff of FC3 to fedora legacy is also delayed > a month ? Yes, I do believe that is correct. -- Jesse Keating Release Engineer: Fedora From paul at city-fan.org Mon Dec 19 17:22:24 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 19 Dec 2005 17:22:24 +0000 Subject: bittorrent in core? what frontend? In-Reply-To: <1135012685.2976.21.camel@tameshk.bamdad.org> References: <1134662961.28842.128.camel@greebo> <20051215202126.GA4210@devserv.devel.redhat.com> <1134721846.28842.166.camel@greebo> <20051217070856.GD24500@devserv.devel.redhat.com> <1134979247.28842.210.camel@greebo> <43A6E55D.9070303@city-fan.org> <1135012685.2976.21.camel@tameshk.bamdad.org> Message-ID: <43A6EC50.80105@city-fan.org> Roozbeh Pournader wrote: > On Mon, 2005-12-19 at 16:52 +0000, Paul Howarth wrote: > >>[...] but on the other hand the alert >>will let them know that a new version is available, and that might >>prompt them to run "yum update" if they don't have automatic updates >>turned on. > > > But on the yet other hand the update may not be available in the yum > repository yet (and may not even be there six months later if it's not > an important update), which will simply frustrate them. Well, as the maintainer of the bittorrent package, at least whilst it's in Extras, I can assure you that updates won't take anything like 6 months to turn up ;-) Paul. From roozbeh at farsiweb.info Mon Dec 19 17:43:35 2005 From: roozbeh at farsiweb.info (Roozbeh Pournader) Date: Mon, 19 Dec 2005 21:13:35 +0330 Subject: bittorrent in core? what frontend? In-Reply-To: <43A6EC50.80105@city-fan.org> References: <1134662961.28842.128.camel@greebo> <20051215202126.GA4210@devserv.devel.redhat.com> <1134721846.28842.166.camel@greebo> <20051217070856.GD24500@devserv.devel.redhat.com> <1134979247.28842.210.camel@greebo> <43A6E55D.9070303@city-fan.org> <1135012685.2976.21.camel@tameshk.bamdad.org> <43A6EC50.80105@city-fan.org> Message-ID: <1135014215.2976.28.camel@tameshk.bamdad.org> On Mon, 2005-12-19 at 17:22 +0000, Paul Howarth wrote: > > But on the yet other hand the update may not be available in the yum > > repository yet (and may not even be there six months later if it's not > > an important update), which will simply frustrate them. > > Well, as the maintainer of the bittorrent package, at least whilst it's > in Extras, I can assure you that updates won't take anything like 6 > months to turn up ;-) But not if it's taken into Core. The update may simply be not important enough, and the current practice of Core is something like "if it's not SECURITY, convince the packager that the update is needed for FC$stable" or you won't get an update. roozbeh From mirandam at gmail.com Mon Dec 19 17:47:19 2005 From: mirandam at gmail.com (Mauriat Miranda) Date: Mon, 19 Dec 2005 12:47:19 -0500 Subject: Fedora Core 5 Test 2 slipping until January 16 In-Reply-To: <1135012482.28062.26.camel@yoda.loki.me> References: <1135012482.28062.26.camel@yoda.loki.me> Message-ID: <8843055e0512190947te6289a2j1a1dfa1bb44e4dce@mail.gmail.com> On 12/19/05, Jesse Keating wrote: > Ok, it won't be a full month, but due to the recent upgrade of gcc and > the subsequent full rebuild of everything that does (and doesn't, > whoops!) get built with gcc, including java stuff with gcj, and the need > to further test package selection windows in Anaconda, > system-config-packages for upgrades, and the development tree in general > once we settle down the rebuilds, we have decided to delay test2. Here > is a new schedule that we will be working toward: Curious: Does anyone know if the alternative install methods (ex: hard drive ISO) will be working by Test2? They were not available in Test1. Mauriat From paul at city-fan.org Mon Dec 19 17:47:12 2005 From: paul at city-fan.org (Paul Howarth) Date: Mon, 19 Dec 2005 17:47:12 +0000 Subject: bittorrent in core? what frontend? In-Reply-To: <1135014215.2976.28.camel@tameshk.bamdad.org> References: <1134662961.28842.128.camel@greebo> <20051215202126.GA4210@devserv.devel.redhat.com> <1134721846.28842.166.camel@greebo> <20051217070856.GD24500@devserv.devel.redhat.com> <1134979247.28842.210.camel@greebo> <43A6E55D.9070303@city-fan.org> <1135012685.2976.21.camel@tameshk.bamdad.org> <43A6EC50.80105@city-fan.org> <1135014215.2976.28.camel@tameshk.bamdad.org> Message-ID: <43A6F220.3040304@city-fan.org> Roozbeh Pournader wrote: > On Mon, 2005-12-19 at 17:22 +0000, Paul Howarth wrote: > >>>But on the yet other hand the update may not be available in the yum >>>repository yet (and may not even be there six months later if it's not >>>an important update), which will simply frustrate them. >> >>Well, as the maintainer of the bittorrent package, at least whilst it's >>in Extras, I can assure you that updates won't take anything like 6 >>months to turn up ;-) > > > But not if it's taken into Core. The update may simply be not important > enough, and the current practice of Core is something like "if it's not > SECURITY, convince the packager that the update is needed for > FC$stable" or you won't get an update. If bittorrent was in Core, it would be quite reasonable for the packager to take a different view of whether or not to leave the update notification enabled, I agree. But for the time being, it's in Extras and I'm inclined to leave it the way it is. Paul. From katzj at redhat.com Mon Dec 19 17:50:26 2005 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 19 Dec 2005 12:50:26 -0500 Subject: Fedora Core 5 Test 2 slipping until January 16 In-Reply-To: <8843055e0512190947te6289a2j1a1dfa1bb44e4dce@mail.gmail.com> References: <1135012482.28062.26.camel@yoda.loki.me> <8843055e0512190947te6289a2j1a1dfa1bb44e4dce@mail.gmail.com> Message-ID: <1135014626.9541.20.camel@bree.local.net> On Mon, 2005-12-19 at 12:47 -0500, Mauriat Miranda wrote: > On 12/19/05, Jesse Keating wrote: > > Ok, it won't be a full month, but due to the recent upgrade of gcc and > > the subsequent full rebuild of everything that does (and doesn't, > > whoops!) get built with gcc, including java stuff with gcj, and the need > > to further test package selection windows in Anaconda, > > system-config-packages for upgrades, and the development tree in general > > once we settle down the rebuilds, we have decided to delay test2. Here > > is a new schedule that we will be working toward: > > Curious: Does anyone know if the alternative install methods (ex: hard > drive ISO) will be working by Test2? They were not available in Test1. Yep, they should be. And we'll test before then even to make sure that they do ;-) Jeremy From linux_4ever at yahoo.com Mon Dec 19 18:10:38 2005 From: linux_4ever at yahoo.com (Steve G) Date: Mon, 19 Dec 2005 10:10:38 -0800 (PST) Subject: boot faster In-Reply-To: <1134941292.4161.7.camel@pmac.infradead.org> Message-ID: <20051219181038.1695.qmail@web51505.mail.yahoo.com> >Given the current extremely broken default of actually _enabling_ >auditing on a rawhide install, 7 seconds wouldn't shock me so much. Audit is enabled by default for rawhide to find bugs. It has successfully found bugs by being enabled by default. When FC5 gets close to finishing up development work, I'll disable it by default. >We really shouldn't be running auditd and enabling syscall auditing on a >default install. In fact, I think auditd itself ought to be in Extras if >it's in Fedora at all. The audit system is required for any troubleshooting of SE Linux. There is a bugzilla opened to address changes to improve performance. I'm certain speed improvements can be made. -Steve __________________________________________________ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com From seanlkml at sympatico.ca Mon Dec 19 18:38:06 2005 From: seanlkml at sympatico.ca (Sean) Date: Mon, 19 Dec 2005 13:38:06 -0500 (EST) Subject: bittorrent in core? what frontend? In-Reply-To: <43A6E55D.9070303@city-fan.org> References: <1134662961.28842.128.camel@greebo> <20051215202126.GA4210@devserv.devel.redhat.com> <1134721846.28842.166.camel@greebo> <20051217070856.GD24500@devserv.devel.redhat.com> <1134979247.28842.210.camel@greebo> <43A6E55D.9070303@city-fan.org> Message-ID: On Mon, December 19, 2005 11:52 am, Paul Howarth said: > I've pushed an update to 4.2.2 earlier today. I'm not sure about > disabling the "updated version" check. On the one hand people should > only be updating the package using RPM, but on the other hand the alert > will let them know that a new version is available, and that might > prompt them to run "yum update" if they don't have automatic updates > turned on. Great. I must have just upgraded a bit before your push. As for the auto-update feature, the user already has utilities that notify them when an update is available; why a special update notice for this one little app? Also, a naive user might not understand that they should wait for the update to appear via their normal update process. Also, an admin might turn off the regular auto-updating for users and not know he has to do something special to shut off this one app. All in all, there are a lot of reasons that having a separate update notification available for this app. Cheers, Sean From mailinglists at erwinrol.com Mon Dec 19 18:43:36 2005 From: mailinglists at erwinrol.com (Erwin Rol) Date: Mon, 19 Dec 2005 19:43:36 +0100 Subject: OOo on x86_64 In-Reply-To: <1134758989.14717.9.camel@localhost.localdomain> References: <1134740785.22855.2.camel@xpc.home.erwinrol.com> <1134758989.14717.9.camel@localhost.localdomain> Message-ID: <1135017816.22855.58.camel@xpc.home.erwinrol.com> OOo still needs mozilla i386 on x86_64 and mozilla i386 still collides with the x86_64 version. Transaction Check Error: file /usr/bin/mozilla from install of mozilla-1.7.12-3 conflicts with file from package mozilla-1.7.12-3 file /usr/share/man/man1/mozilla.1.gz from install of mozilla-1.7.12-3 conflicts with file from package mozilla-1.7.12-3 Am I the only one with this problem ? - Erwin BTW that yum error message is not very useful "package A conflicts with package A", better would be "package A.i386 conflicts with package A.x86_64" On Fri, 2005-12-16 at 13:49 -0500, Dennis Gregorovic wrote: > On Fri, 2005-12-16 at 14:46 +0100, Erwin Rol wrote: > > OOo still pulls in mozilla.i386 and libgjc.i386 and those two packages > > cause problems for me, when I try to install them they seem to collide > > with the x86_64 versions. > > > > Transaction Check Error: file /usr/share/java/libgcj-4.1.0.jar from > > install of libgcj-4.1.0-0.8 conflicts with file from package > > libgcj-4.1.0-0.8 > > > > Transaction Check Error: file /usr/bin/mozilla from install of > > mozilla-1.7.12-3 conflicts with file from package mozilla-1.7.12-3 > > file /usr/share/man/man1/mozilla.1.gz from install of mozilla-1.7.12-3 > > conflicts with file from package mozilla-1.7.12-3 > > > > > > - Erwin > > Thanks for the update. Caolon is working on the fix. > > -- Dennis > From zaitcev at redhat.com Mon Dec 19 18:43:55 2005 From: zaitcev at redhat.com (Pete Zaitcev) Date: Mon, 19 Dec 2005 10:43:55 -0800 Subject: libusual interface [was Re: libusual and ub] In-Reply-To: <20051219164058.GC12747@devserv.devel.redhat.com> References: <20051215031822.GA12020@devserv.devel.redhat.com> <20051214211008.22c1ae47.zaitcev@redhat.com> <20051215053741.GA13787@devserv.devel.redhat.com> <20051215002129.4e9863e0.zaitcev@redhat.com> <1134655233.2864.31.camel@bree.local.net> <20051216001243.446d94e3.zaitcev@redhat.com> <20051217065304.GA24500@devserv.devel.redhat.com> <20051216231839.7c4bc38a.zaitcev@redhat.com> <20051217072150.GG24500@devserv.devel.redhat.com> <20051217013313.3da8bfa2.zaitcev@redhat.com> <20051219164058.GC12747@devserv.devel.redhat.com> Message-ID: <20051219104355.23d57186.zaitcev@redhat.com> On Mon, 19 Dec 2005 11:40:58 -0500, Bill Nottingham wrote: > > > I mean separate the aliases *into the base drivers themselves* - not > > > using libusual at all. i.e., a given usb id only matches one of > > > usb-storage or ub. > > > > Nothing new in this approach either. This is how ub worked way before > > libusual, and before Adrian Bunk broke it. The problem is, users require > > a capability to switch between drivers. And we cannot predict which one > > they want to use for any given device. > > *Why* do they need the capability? Users *should not care* which > driver they use - if they do, one of them needs fixed. Well, such is the theory, but in practice making an alternative driver to handle all cases creates an impossibly high barrier to entry. The common solution is to pass known-good devices from old driver to new driver (e.g. 8139too, e100). This is, unfortunately, impossible in case of USB storage. To answer your specific question, when Bunk was making trouble, ub did not work as well as it does now, so there was an implicit assumption that usb-storage would be superior under some, hitherto unknown, circumstances. Some people were assumed to desire our SCSI stack and old device names. Also, without libusual (not existing back then), there was no exception for USB connected ATAPI tapes. So we did not discuss specific instances of breakage much, and I did not challenge him to produce failure scenarios. -- Pete From camilo at mesias.co.uk Mon Dec 19 18:49:05 2005 From: camilo at mesias.co.uk (Cam) Date: Mon, 19 Dec 2005 18:49:05 +0000 Subject: booting notebooks vs. suspend (was Re: boot faster) In-Reply-To: <1135008807.14566.38.camel@gilboa-work-dev> References: <1134921889.11021.47.camel@localhost.localdomain> <604aa7910512180940v3884a78byfc5445eb0e7dbed2@mail.gmail.com> <1134956408.11021.69.camel@localhost.localdomain> <43A6A655.6080400@redhat.com> <43A6B8C7.5080008@mesias.co.uk> <1135008339.28062.0.camel@yoda.loki.me> <1135008807.14566.38.camel@gilboa-work-dev> Message-ID: <43A700A1.4030008@mesias.co.uk> Gilboa Davara wrote: > Umm... I rarely boot my machines (once in a couple of months), but I'd > venture to guess that if suspend-resume was bullet-proof, people would > have rebooted their machine only in the cases above, which are pretty > rare events for most Linux users. My point exactly. IF you just want to pull the machine out of the bag, open it and use it, then close it and replace it, working ACPI suspend is the perfect solution. Booting becomes a relatively rare event and time to boot is less significant. > Plus, I might be wrong here, but doesn't suspend to disk theoretically > allows you to suspend, switch to Windows (*spit!), and pick up where you > left once you switch back to Linux? Probably - I use ACPI suspend to RAM, I haven't tried the suspend2 (to disk) but I imagine it's slower. If I wanted to use the other OS it's easier for me to use a vmware image than reboot. -Cam -- <-- camilo at mesias.co.uk From dmalcolm at redhat.com Mon Dec 19 18:54:25 2005 From: dmalcolm at redhat.com (David Malcolm) Date: Mon, 19 Dec 2005 13:54:25 -0500 Subject: rawhide report: 20051218 changes In-Reply-To: <1134912913.3637.14.camel@T7.Linux> References: <200512180834.jBI8YatH014352@porkchop.devel.redhat.com> <1134912913.3637.14.camel@T7.Linux> Message-ID: <1135018465.7158.39.camel@cassandra.boston.redhat.com> On Sun, 2005-12-18 at 13:35 +0000, Paul F. Johnson wrote: > Hi, > > > Broken deps for x86_64 > > ---------------------------------------------------------- > > I keep getting libebook is needed by nautilus-sendto. Is this down to me > or is it a packaging problem (libebook is from evolution IIRC) evolution-data-server It's a library for getting at your addressbook/contacts, so it seems like a reasonable dep for nautilus-sendto to me. If you're still running into problems, please BZ it. Thanks Dave From jkeating at j2solutions.net Mon Dec 19 18:58:57 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Mon, 19 Dec 2005 10:58:57 -0800 Subject: bittorrent in core? what frontend? In-Reply-To: <33933.10.10.10.28.1135017486.squirrel@linux1> References: <1134662961.28842.128.camel@greebo> <20051215202126.GA4210@devserv.devel.redhat.com> <1134721846.28842.166.camel@greebo> <20051217070856.GD24500@devserv.devel.redhat.com> <1134979247.28842.210.camel@greebo> <43A6E55D.9070303@city-fan.org> <33933.10.10.10.28.1135017486.squirrel@linux1> Message-ID: <1135018737.28062.53.camel@yoda.loki.me> On Mon, 2005-12-19 at 13:38 -0500, Sean wrote: > All in all, there are a lot of reasons that having a separate update > notification available for this app. I agree. It would be highly confusing to a user to get notices for an update and for them to try and update it in the generic way such notices will give them. Firefox fits into this category as well, and I don't believe it notifies users of pending updates in Fedora. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) Was I helpful? Let others know: http://svcs.affero.net/rm.php?r=jkeating From notting at redhat.com Mon Dec 19 19:01:18 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Dec 2005 14:01:18 -0500 Subject: libusual interface [was Re: libusual and ub] In-Reply-To: <20051219104355.23d57186.zaitcev@redhat.com> References: <20051215053741.GA13787@devserv.devel.redhat.com> <20051215002129.4e9863e0.zaitcev@redhat.com> <1134655233.2864.31.camel@bree.local.net> <20051216001243.446d94e3.zaitcev@redhat.com> <20051217065304.GA24500@devserv.devel.redhat.com> <20051216231839.7c4bc38a.zaitcev@redhat.com> <20051217072150.GG24500@devserv.devel.redhat.com> <20051217013313.3da8bfa2.zaitcev@redhat.com> <20051219164058.GC12747@devserv.devel.redhat.com> <20051219104355.23d57186.zaitcev@redhat.com> Message-ID: <20051219190118.GA10337@devserv.devel.redhat.com> Pete Zaitcev (zaitcev at redhat.com) said: > > *Why* do they need the capability? Users *should not care* which > > driver they use - if they do, one of them needs fixed. > > Well, such is the theory, but in practice making an alternative driver > to handle all cases creates an impossibly high barrier to entry. > The common solution is to pass known-good devices from old driver to > new driver (e.g. 8139too, e100). This is, unfortunately, impossible > in case of USB storage. That's what I'm asking - why is it impossible? We've turned off things like eepro100, so I'm not sure why disabling usb-storage for X, Y, and Z would be a problem. After all, anything left couldn't be worse than firewire. :) Bill From ellson at research.att.com Mon Dec 19 19:04:51 2005 From: ellson at research.att.com (John Ellson) Date: Mon, 19 Dec 2005 14:04:51 -0500 Subject: OOo on x86_64 In-Reply-To: <1135017816.22855.58.camel@xpc.home.erwinrol.com> References: <1134740785.22855.2.camel@xpc.home.erwinrol.com> <1134758989.14717.9.camel@localhost.localdomain> <1135017816.22855.58.camel@xpc.home.erwinrol.com> Message-ID: <43A70453.8090007@research.att.com> Erwin Rol wrote: > OOo still needs mozilla i386 on x86_64 and mozilla i386 still collides > with the x86_64 version. > > Transaction Check Error: file /usr/bin/mozilla from install of > mozilla-1.7.12-3 conflicts with file from package mozilla-1.7.12-3 > file /usr/share/man/man1/mozilla.1.gz from install of mozilla-1.7.12-3 > conflicts with file from package mozilla-1.7.12-3 > > Am I the only one with this problem ? > No, I think we're all seeing it. Basically there are just two files that conflict: the script /usr/bin/mozilla and the man page. If you want a workaround you can try this. It works for me, but use at your own risk. rpm -Uvh --force --relacepkgs mozilla-1.7.12-3.i386.rpm rpm -Uvh --force --relacepkgs mozilla-1.7.12-3.x86_64.rpm That leaves the x86_64 version of mozilla in /usr/bin/mozilla and provides an i386 version of /usr/lib/mozilla/libxpcom.so that can be used by openoffice.org. John From davej at redhat.com Mon Dec 19 19:17:08 2005 From: davej at redhat.com (Dave Jones) Date: Mon, 19 Dec 2005 14:17:08 -0500 Subject: libusual interface [was Re: libusual and ub] In-Reply-To: <20051219190118.GA10337@devserv.devel.redhat.com> References: <20051215002129.4e9863e0.zaitcev@redhat.com> <1134655233.2864.31.camel@bree.local.net> <20051216001243.446d94e3.zaitcev@redhat.com> <20051217065304.GA24500@devserv.devel.redhat.com> <20051216231839.7c4bc38a.zaitcev@redhat.com> <20051217072150.GG24500@devserv.devel.redhat.com> <20051217013313.3da8bfa2.zaitcev@redhat.com> <20051219164058.GC12747@devserv.devel.redhat.com> <20051219104355.23d57186.zaitcev@redhat.com> <20051219190118.GA10337@devserv.devel.redhat.com> Message-ID: <20051219191708.GC10028@redhat.com> On Mon, Dec 19, 2005 at 02:01:18PM -0500, Bill Nottingham wrote: > Pete Zaitcev (zaitcev at redhat.com) said: > > > *Why* do they need the capability? Users *should not care* which > > > driver they use - if they do, one of them needs fixed. > > > > Well, such is the theory, but in practice making an alternative driver > > to handle all cases creates an impossibly high barrier to entry. > > The common solution is to pass known-good devices from old driver to > > new driver (e.g. 8139too, e100). This is, unfortunately, impossible > > in case of USB storage. > > That's what I'm asking - why is it impossible? We've turned off > things like eepro100, so I'm not sure why disabling usb-storage > for X, Y, and Z would be a problem. After all, anything left couldn't > be worse than firewire. :) The most obvious one to me is things like eepro100 supported about a dozen cards. usb-storage supports thousands of devices. Whitelisting those isn't really practical. Dave From notting at redhat.com Mon Dec 19 19:19:49 2005 From: notting at redhat.com (Bill Nottingham) Date: Mon, 19 Dec 2005 14:19:49 -0500 Subject: libusual interface [was Re: libusual and ub] In-Reply-To: <20051219191708.GC10028@redhat.com> References: <1134655233.2864.31.camel@bree.local.net> <20051216001243.446d94e3.zaitcev@redhat.com> <20051217065304.GA24500@devserv.devel.redhat.com> <20051216231839.7c4bc38a.zaitcev@redhat.com> <20051217072150.GG24500@devserv.devel.redhat.com> <20051217013313.3da8bfa2.zaitcev@redhat.com> <20051219164058.GC12747@devserv.devel.redhat.com> <20051219104355.23d57186.zaitcev@redhat.com> <20051219190118.GA10337@devserv.devel.redhat.com> <20051219191708.GC10028@redhat.com> Message-ID: <20051219191949.GA29562@devserv.devel.redhat.com> Dave Jones (davej at redhat.com) said: > The most obvious one to me is things like eepro100 supported > about a dozen cards. usb-storage supports thousands of devices. > Whitelisting those isn't really practical. Nah, just fix the bugs as they come in... :) Bill From ph18 at cornell.edu Mon Dec 19 19:59:46 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Mon, 19 Dec 2005 14:59:46 -0500 Subject: bittorrent in core? what frontend? In-Reply-To: <1135018737.28062.53.camel@yoda.loki.me> References: <1134662961.28842.128.camel@greebo> <20051215202126.GA4210@devserv.devel.redhat.com> <1134721846.28842.166.camel@greebo> <20051217070856.GD24500@devserv.devel.redhat.com> <1134979247.28842.210.camel@greebo> <43A6E55D.9070303@city-fan.org> <33933.10.10.10.28.1135017486.squirrel@linux1> <1135018737.28062.53.camel@yoda.loki.me> Message-ID: <43A71132.5040406@cornell.edu> Jesse Keating wrote: > On Mon, 2005-12-19 at 13:38 -0500, Sean wrote: > >> All in all, there are a lot of reasons that having a separate update >> notification available for this app. >> > > I agree. It would be highly confusing to a user to get notices for an > update and for them to try and update it in the generic way such notices > will give them. Firefox fits into this category as well, and I don't > believe it notifies users of pending updates in Fedora. > > Also, this kind of nonsense is one of things that makes running Windows so miserable today... For instance, Acroread pops up a modal dialog, asking me if I want to install some junkware I've never heard of, that freezes Firefox -- this modal dialog can be hard to find sometimes, so I end up having to kill Firefox. I have to supervise the Windows machine for a minute or so when I turn it off, which is a real pain when I'm running late for the bus at the end of the work day. From dragoran at feuerpokemon.de Mon Dec 19 20:12:47 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Mon, 19 Dec 2005 21:12:47 +0100 Subject: OOo on x86_64 In-Reply-To: <43A70453.8090007@research.att.com> References: <1134740785.22855.2.camel@xpc.home.erwinrol.com> <1134758989.14717.9.camel@localhost.localdomain> <1135017816.22855.58.camel@xpc.home.erwinrol.com> <43A70453.8090007@research.att.com> Message-ID: <43A7143F.5010409@feuerpokemon.de> John Ellson wrote: > Erwin Rol wrote: > >> OOo still needs mozilla i386 on x86_64 and mozilla i386 still collides >> with the x86_64 version. >> Transaction Check Error: file /usr/bin/mozilla from install of >> mozilla-1.7.12-3 conflicts with file from package mozilla-1.7.12-3 >> file /usr/share/man/man1/mozilla.1.gz from install of mozilla-1.7.12-3 >> conflicts with file from package mozilla-1.7.12-3 >> >> Am I the only one with this problem ? >> > > No, I think we're all seeing it. > > Basically there are just two files that conflict: the script > /usr/bin/mozilla > and the man page. If you want a workaround you can try this. It works > for me, but use at your own risk. > > rpm -Uvh --force --relacepkgs mozilla-1.7.12-3.i386.rpm > rpm -Uvh --force --relacepkgs mozilla-1.7.12-3.x86_64.rpm > > That leaves the x86_64 version of mozilla in /usr/bin/mozilla > and provides an i386 version of /usr/lib/mozilla/libxpcom.so > that can be used by openoffice.org. > > John > > can we split mozilla into mozilla-browser and mozilla-libs to avoid that? (at least until it is possible to have a x86_64 OO build) From i at stingr.net Mon Dec 19 20:16:53 2005 From: i at stingr.net (Paul P Komkoff Jr) Date: Mon, 19 Dec 2005 23:16:53 +0300 Subject: Too much time wasted installing fedora on raid1 Message-ID: <20051219201653.GU1556@stingr.net> Hello. Last N systems I've installed, I am usually assembling software raid1 at install time. The disk layout I'm using is trivial: 100MB + the rest, where on 1st 100MB is /dev/md0 (ext3, /boot) and the rest is /dev/md1 (lvm, other). For whatever reason (haven't looked at the code yet :() anaconda issuing mdadm commands in such order that primary replica of unsynched md0 is second drive, and raid1 resync started first on md1. So, to boot without changing bios settings back and forth (or without disabling 1st disk drive by any other means) it is nesessary to wait while md1 raid1 resyncs, which can be as long as 2 hours (250GB HDD). I've not tried fc5 test1 yet, but I'm pretty sure that without any additional steps to reslove this issue it couldn't just vaporize. So, is it possible to change anaconda wrt described issue? -- Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key This message represents the official view of the voices in my head From darrellpf at gmail.com Mon Dec 19 20:32:20 2005 From: darrellpf at gmail.com (darrell pfeifer) Date: Mon, 19 Dec 2005 12:32:20 -0800 Subject: unicode characters Message-ID: (This is a resend...sorry if you see it twice but the original version didn't seem to be on the list after two hours) I am running the latest rawhide. Sometime in the last several days some of my unicode characters have started appearing as the "unrecognized" empty square (I don't know what it is officially called). This is true for www.chinesepod.com, which is mostly in English but has a few Chinese symbols. It is also happens in Eclipse with Java source code, mostly before and after the double quote character. I'm using the non-gcj version of Eclipse. The file appears normally using kwrite. My language settings have been UTF-8 for a long time. I've seen this happen once before and it seemed to correct itself with font updates. Any suggestions on where to look? thanks darrell From arjan at fenrus.demon.nl Mon Dec 19 21:12:32 2005 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Mon, 19 Dec 2005 22:12:32 +0100 Subject: Too much time wasted installing fedora on raid1 In-Reply-To: <20051219201653.GU1556@stingr.net> References: <20051219201653.GU1556@stingr.net> Message-ID: <1135026753.2947.23.camel@laptopd505.fenrus.org> On Mon, 2005-12-19 at 23:16 +0300, Paul P Komkoff Jr wrote: > Hello. > > Last N systems I've installed, I am usually assembling software raid1 > at install time. The disk layout I'm using is trivial: 100MB + > the rest, where on 1st 100MB is /dev/md0 (ext3, /boot) and the rest is > /dev/md1 (lvm, other). > > For whatever reason (haven't looked at the code yet :() anaconda > issuing mdadm commands in such order that primary replica of unsynched > md0 is second drive, and raid1 resync started first on md1. > > So, to boot without changing bios settings back and forth (or without > disabling 1st disk drive by any other means) it is nesessary to wait > while md1 raid1 resyncs, which can be as long as 2 hours (250GB HDD). I'm pretty sure that anaconda at some point deliberately did things to avoid that sync. So I suspect it got reenabled for a good reason... From mailinglists at erwinrol.com Mon Dec 19 21:16:50 2005 From: mailinglists at erwinrol.com (Erwin Rol) Date: Mon, 19 Dec 2005 22:16:50 +0100 Subject: Mesa-6.4.1 now available for Fedora devel In-Reply-To: <43A6B066.8040807@mharris.ca> References: <43A6B066.8040807@mharris.ca> Message-ID: <1135027010.22855.77.camel@xpc.home.erwinrol.com> On Mon, 2005-12-19 at 08:06 -0500, Mike A. Harris wrote: > There will be a new X11R7 RC4 X server soon, along with all of the > RC4 drivers as well. The rest of the RC4 packages not already in > rawhide will hopefully all be built today, and end up in tomorrow's > rawhide push. > would it be possible to add Benjamin's patch for the Radeon cards ? It seems that for some ppl it fixed a hard hang. The thread with the patch starts here; http://lists.freedesktop.org/archives/xorg/2005-December/011678.html - Erwin From dominik at greysector.net Mon Dec 19 22:43:22 2005 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Mon, 19 Dec 2005 23:43:22 +0100 Subject: kernel-2.6.14-1.1653_FC4.netdev.6? In-Reply-To: <20051216225617.GC4376@rathann.pekin.waw.pl> References: <43A05044.7060803@cygnusx-1.org> <20051215005152.GF26108@rathann.pekin.waw.pl> <20051215010803.GE9801@redhat.com> <20051215162712.GC16712@redhat.com> <20051215215952.GC4336@rathann.pekin.waw.pl> <20051216131221.GA9708@redhat.com> <20051216225617.GC4376@rathann.pekin.waw.pl> Message-ID: <20051219224322.GA5815@rathann.pekin.waw.pl> On Friday, 16 December 2005 at 23:56, Dominik 'Rathann' Mierzejewski wrote: > On Friday, 16 December 2005 at 14:12, John W. Linville wrote: [...] > > Please note that the FC4.jwltest kernels do _not_ have the collection > > of upstream networking fixes that are in the FC4.netdev series. > > Also, don't blame me if you laptop explodes...ha-ha, only serious. > > :) > Anyway, until "DSDT in initrd" patch becomes part of FC kernels, I might > as well stick to what I do, because changing a few config params is far > less invasive and time consuming than applying a patch to released kernels. I tested the DSDT in initrd patch and it seems to be working fine with netdev.6 kernel. However, my ipw2200 is still inoperable. Where do I submit a bugreport? Presently, even though I have all firmwares from 2.2 to 2.4, it still fails with ieee80211_crypt: registered algorithm 'NULL' ieee80211: 802.11 data/management/control stack, git-1.1.7 ieee80211: Copyright (C) 2004-2005 Intel Corporation ipw2200: Intel(R) PRO/Wireless 2200/2915 Network Driver, git-1.0.8 ipw2200: Copyright(c) 2003-2005 Intel Corporation ACPI: PCI Interrupt 0000:05:03.0[A] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11 ipw2200: Detected Intel PRO/Wireless 2915ABG Network Connection ipw2200: Failed to send TX_POWER: Command timed out. ipw2200: Failed to send TX_POWER: Command timed out. ipw2200: Failed to send TX_POWER: Command timed out. ipw2200: Failed to send TX_POWER: Command timed out. ipw2200: Failed to send TX_POWER: Command timed out. ipw2200: Unable to initialize device after 5 attempts. ipw2200: failed to register network device ACPI: PCI interrupt for device 0000:05:03.0 disabled ipw2200: probe of 0000:05:03.0 failed with error -5 ieee80211_crypt: unregistered algorithm 'NULL' lspci -nv snippet: 05:03.0 Class 0280: 8086:4223 (rev 05) Subsystem: 8086:1001 Flags: medium devsel, IRQ 11 Memory at c8214000 (32-bit, non-prefetchable) [size=4K] Capabilities: [dc] Power Management version 2 Additionally, I can't turn on debugging. modprobe ipw2200 debug=0xffff output is no more verbose than without the debug option. Regards, R. -- APT/YUM RPM repository for Fedora Core http://rpm.greysector.net/ mpg321, xmp, faad2, lame, mad, *mplayer*, rdesktop, tin, xvid, mks, mutt "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From gilboad at gmail.com Tue Dec 20 00:11:19 2005 From: gilboad at gmail.com (Gilboa Davara) Date: Tue, 20 Dec 2005 02:11:19 +0200 Subject: OO x86_64 status? Message-ID: <1135037479.17062.1.camel@gilboa-home-dev.localhost> Hello all, What are the chances of having a fully 64bit Open-Office ready for FC5 release? Does anyone know if the OO.org team managed to stabilize the 64bit builds? Thanks, Gilboa From n0dalus+redhat at gmail.com Tue Dec 20 00:39:05 2005 From: n0dalus+redhat at gmail.com (n0dalus) Date: Tue, 20 Dec 2005 11:09:05 +1030 Subject: Fedora Core 5 Test 2 slipping until January 16 In-Reply-To: <1135014626.9541.20.camel@bree.local.net> References: <1135012482.28062.26.camel@yoda.loki.me> <8843055e0512190947te6289a2j1a1dfa1bb44e4dce@mail.gmail.com> <1135014626.9541.20.camel@bree.local.net> Message-ID: <6280325c0512191639t1c4e6733q1ebffd06bc73a702@mail.gmail.com> On 12/20/05, Jeremy Katz wrote: > On Mon, 2005-12-19 at 12:47 -0500, Mauriat Miranda wrote: > > > > Curious: Does anyone know if the alternative install methods (ex: hard > > drive ISO) will be working by Test2? They were not available in Test1. > > Yep, they should be. And we'll test before then even to make sure that > they do ;-) > > Jeremy > Can someone point me to some information about non-CD installs? I would like to give it a shot for the next test release. Thanks, n0dalus. From mpeters at mac.com Tue Dec 20 01:27:57 2005 From: mpeters at mac.com (Michael A. Peters) Date: Mon, 19 Dec 2005 17:27:57 -0800 Subject: unicode characters In-Reply-To: References: Message-ID: <1135042078.2798.40.camel@locolhost.localdomain> On Mon, 2005-12-19 at 12:32 -0800, darrell pfeifer wrote: > > My language settings have been UTF-8 for a long time. I've seen this > happen once before and it seemed to correct itself with font updates. > > Any suggestions on where to look? fontconfig - if you know you have fonts installed that it should look at. I think the bug would be in fontconfig if anywhere, it is suppose to grab the glyphs from a font that has them if the font you are using does not. At least I think that is what it is suppose to do. From admin at ramshacklestudios.com Sun Dec 18 22:19:02 2005 From: admin at ramshacklestudios.com (Peter Gordon) Date: Sun, 18 Dec 2005 14:19:02 -0800 Subject: gnome 2.12 for fc4? In-Reply-To: <43A51437.4000602@feuerpokemon.de> References: <43A3E646.4070100@feuerpokemon.de> <1134848345.752.7.camel@tuxhugger> <43A51437.4000602@feuerpokemon.de> Message-ID: <1134944342.3417.5.camel@tuxhugger> On Sun, 2005-12-18 at 08:48 +0100, dragoran wrote: > I hate replacing core packages with third party ones. I do, also. :-) -- Peter Gordon (codergeek42) GnuPG Public Key: 0xDA3634D7 -------------- 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 nman64 at n-man.com Tue Dec 20 04:41:20 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Mon, 19 Dec 2005 22:41:20 -0600 Subject: Happy Holidays from Fedora Mentors! Message-ID: <43A78B70.3040808@n-man.com> Happy Holidays from the Fedora Mentors team! We want to bring in the new year with the Fedora Project in an awesome way. We want to boost the Fedora contributor base just in time to help us shove Fedora Core 5 out the door. Here is the Fedora Mentors New Year's Challenge: Fedora Fans (end-users): So you've enjoyed using Fedora, or have had a little trouble and gotten help from the Fedora Community, but have you ever thought about how you can make a significant contribution to this great project? You might be surprised as to just how many ways there are for you to contribute. Our challenge for you is simple: get started as a Fedora contributor. As a subscriber to this list, you've already taken the first steps. The Fedora Mentors program is here to help you go the rest of the way! For starters, visit our HelpWanted[1] page to get some ideas as to how you can help us. Once you know what you want to do, you can visit the Fedora Mentors home[2] to learn how you can get guidance for every step of you journey with Fedora. Complete this challenge and be part of something grand! Fedora Contributors: Thanks for helping us out. We're glad to have every contributor as part of the team. That said, we can never have enough people helping to drive Fedora forward. That is why our challenge for you is to select someone and help them join the Fedora Project as a contributor. It doesn't matter who you select; it can be someone in one of Fedora's end-user channels, a friend, family member, or someone in your community who is curious about open source and Fedora. All you have to do is help them to see just how they can make a difference in our project. Help to guide them in selecting a Fedora project to work with. Help them establish first contact, and help them through their first tasks to become a contributor. You've been through this process yourself, so you shouldn't have any trouble guiding them in getting started. If you need any help, we're here to back you up! Stop on by the Fedora Mentors home[2] for information on how we can help you or your new contributor with whatever questions you might have. If this seems like a program you think you can help out with, join us! We would be happy to welcome new Fedora Mentors, and you can easily be a mentor without it interfering with your other Fedora contributions. It's easy work! Complete this challenge and you can be truly proud of your accomplishments with the Fedora Project! [1] http://fedoraproject.org/wiki/HelpWanted [2] http://fedoraproject.org/wiki/Mentors -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ -- Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From gianluca.cecchi at gmail.com Tue Dec 20 05:49:02 2005 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Tue, 20 Dec 2005 06:49:02 +0100 Subject: scim-libs not signed error when using yum?? Message-ID: <561c252c0512192149p22498ad0v@mail.gmail.com> Hello, with fc5 devel installed, after syncronizing with ftp.mirror.ac.uk::fedora.redhat.com/development/i386/ and trying to do yum localupdate *rpm under Fedora/RPMS directory, I get [snip] Installing for dependencies: xscreensaver-extras i386 1:4.22-21.2 development 2.9 M Transaction Summary ============================================================================= Install 3 Package(s) Update 16 Package(s) Remove 2 Package(s) Total download size: 116 M Is this ok [y/N]: y Downloading Packages: Package scim-libs-1.4.2-9.i386.rpm is not signed I tried also rpm --import RPM-GPG-KEY under the root i386 dir, but nothing changes. As there are various KEY files, different in size, in this directory, do I have to import all of them? These problem was there also yesterday and with "rpm -Fvh *rpm" the yesterday packages were upgraded (no new instal needed). With the same method I should install xscreensaver-extras and eventually dependancies and then run -Fvh for the rest I would like to wait, going through yum if possible Any hints? yum version is the latest: 2.5.0 Thanks in advance Gianluca PS: This environment is under VMware workstation 5.5 so I can trick with snapshots or similar if useful. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at redhat.com Tue Dec 20 05:58:32 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Tue, 20 Dec 2005 11:28:32 +0530 Subject: scim-libs not signed error when using yum?? In-Reply-To: <561c252c0512192149p22498ad0v@mail.gmail.com> References: <561c252c0512192149p22498ad0v@mail.gmail.com> Message-ID: <43A79D88.3090301@redhat.com> Gianluca Cecchi wrote: > Hello, > with fc5 devel installed, after syncronizing with > ftp.mirror.ac.uk::fedora.redhat.com/development/i386/ > and trying to do > yum localupdate *rpm > under Fedora/RPMS directory, I get > > [snip] > Installing for dependencies: > xscreensaver-extras i386 1:4.22-21.2 development > 2.9 M > > Transaction Summary > ============================================================================= > Install 3 Package(s) > Update 16 Package(s) > Remove 2 Package(s) > Total download size: 116 M > Is this ok [y/N]: y > Downloading Packages: > > > Package scim-libs-1.4.2-9.i386.rpm is not signed > > I tried also rpm --import RPM-GPG-KEY under the root i386 dir, > but nothing changes. > As there are various KEY files, different in size, in this directory, > do I have to import all of them? You can try importing all of the keys or disable gpg key check just for the rawhide installation. > These problem was there also yesterday and with "rpm -Fvh *rpm" the > yesterday packages > were upgraded (no new instal needed). With the same method I should > install > xscreensaver-extras and eventually dependancies and then run -Fvh for > the rest > I would like to wait, going through yum if possible > Any hints? yum install xscreensaver-extras works fine here. regards Rahul From gianluca.cecchi at gmail.com Tue Dec 20 06:12:42 2005 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Tue, 20 Dec 2005 07:12:42 +0100 Subject: scim-libs not signed error when using yum?? In-Reply-To: <561c252c0512192149p22498ad0v@mail.gmail.com> References: <561c252c0512192149p22498ad0v@mail.gmail.com> Message-ID: <561c252c0512192212n1085342g@mail.gmail.com> >> You can try importing all of the keys or disable gpg key check just for the rawhide installation. Imported all the RPM-GPG keys files, but nothing changes. Also, the command "yum localinstall xscreensaver-extra" gives the same error about xscreensaver-extra not being signed.... How to disable gpg check? Is it safe? >>yum install xscreensaver-extras works fine here. It works also for me, but I would like not to download packages two times, one for syncronizing and one for updating... Gianluca -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at redhat.com Tue Dec 20 06:26:40 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Tue, 20 Dec 2005 11:56:40 +0530 Subject: scim-libs not signed error when using yum?? In-Reply-To: <561c252c0512192212n1085342g@mail.gmail.com> References: <561c252c0512192149p22498ad0v@mail.gmail.com> <561c252c0512192212n1085342g@mail.gmail.com> Message-ID: <43A7A420.4020607@redhat.com> Gianluca Cecchi wrote: > >> You can try importing all of the keys or disable gpg key check just > for the rawhide installation. > > Imported all the RPM-GPG keys files, but nothing changes. > Also, the command "yum localinstall xscreensaver-extra" gives the same > error > about xscreensaver-extra not being signed.... > How to disable gpg check? Is it safe? > >>>yum install xscreensaver-extras works fine here. > > > It works also for me, but I would like not to download packages two > times, one for syncronizing and one for updating... > Gianluca > Not sure what you mean here. Yum checks the repository and downloads the repository metadata once if the local cache is not in sync with the mirror and then downloads the packages requested. Subsequent runs of Yum on rawhide does not redownload metadata and uses the local cache for the specified expiration period which is controlled by the metadata_expire in yum.conf with the default value of 1800 (seconds). If you perform a network installation you are only downloading these packages once. In any case the number of times you download a package does not vary while using yum as compared to RPM. regards Rahul From petersen at redhat.com Tue Dec 20 06:32:03 2005 From: petersen at redhat.com (Jens Petersen) Date: Tue, 20 Dec 2005 15:32:03 +0900 Subject: scim-libs not signed error when using yum?? In-Reply-To: <561c252c0512192149p22498ad0v@mail.gmail.com> References: <561c252c0512192149p22498ad0v@mail.gmail.com> Message-ID: <43A7A563.2090101@redhat.com> Gianluca Cecchi wrote: > Package scim-libs-1.4.2-9.i386.rpm is not signed Packages in FC Devel are not usually signed (except for packages included from test releases). Please set "gpgcheck=0" in the appropriate repos file in "/etc/yum.repos.d/". Jens From rodd at clarkson.id.au Tue Dec 20 08:17:43 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Tue, 20 Dec 2005 19:17:43 +1100 Subject: scim-libs not signed error when using yum?? In-Reply-To: <43A79D88.3090301@redhat.com> References: <561c252c0512192149p22498ad0v@mail.gmail.com> <43A79D88.3090301@redhat.com> Message-ID: <1135066664.3149.0.camel@localhost.localdomain> On Tue, 2005-12-20 at 11:28 +0530, Rahul Sundaram wrote: > Gianluca Cecchi wrote: > > > Hello, > > with fc5 devel installed, after syncronizing with > > ftp.mirror.ac.uk::fedora.redhat.com/development/i386/ > > and trying to do > > yum localupdate *rpm > > under Fedora/RPMS directory, I get > > > > [snip] > > Installing for dependencies: > > xscreensaver-extras i386 1:4.22-21.2 development > > 2.9 M > > > > Transaction Summary > > ============================================================================= > > Install 3 Package(s) > > Update 16 Package(s) > > Remove 2 Package(s) > > Total download size: 116 M > > Is this ok [y/N]: y > > Downloading Packages: > > > > > > Package scim-libs-1.4.2-9.i386.rpm is not signed > > > > I tried also rpm --import RPM-GPG-KEY under the root i386 dir, > > but nothing changes. > > As there are various KEY files, different in size, in this directory, > > do I have to import all of them? > > You can try importing all of the keys or disable gpg key check just for > the rawhide installation. > > > These problem was there also yesterday and with "rpm -Fvh *rpm" the > > yesterday packages > > were upgraded (no new instal needed). With the same method I should > > install > > xscreensaver-extras and eventually dependancies and then run -Fvh for > > the rest > > I would like to wait, going through yum if possible > > Any hints? > > yum install xscreensaver-extras works fine here. > > regards > Rahul Try yum update yum and then try to install xcreensaver-extras. I version of yum a few version back did this a bit. Rodd > -- "It's a fine line between denial and faith. It's much better on my side" From buildsys at redhat.com Tue Dec 20 08:19:50 2005 From: buildsys at redhat.com (Build System) Date: Tue, 20 Dec 2005 03:19:50 -0500 Subject: rawhide report: 20051220 changes Message-ID: <200512200819.jBK8JoHM013990@porkchop.devel.redhat.com> New package libvir Library providing an API to use the Xen virtualization Updated Packages: GFS-kernel-2.6.14.1-20051219.162641.FC5.2 ----------------------------------------- * Mon Dec 19 2005 Chris Feist - rebuilt ORBit2-2.13.2-2 --------------- * Mon Dec 19 2005 Matthias Clasen 2.13.2-2 - Fix multilib issues anaconda-10.90.22-1 ------------------- * Mon Dec 19 2005 Jeremy Katz - 10.90.22-1 - add more encoding modules to traceonly (clumens, #175853) - Fix text installs (pnasrat, #175773) - Fix for yum API changes (pnasrat) - Don't install the smp kernel even if NX is available - Adjust to be more dynamic about colors with syslinux-splash's - Use the selected language for default keyboard layout (clumens, #172266) - Better naming for psuedo-filesystems in /etc/fstab (dcantrel, #176149) - Clean up image handling for new graphics - Don't do the splashscreen stuff anymore. If the window is too slow to appear, we should fix that instead arts-8:1.5.0-1 -------------- * Mon Dec 19 2005 Than Ngo 1.5.0-1 - apply patch to fix #169631 automake-1.9.6-2 ---------------- * Mon Dec 19 2005 Karsten Hopp 1.9.6-2 - include NEWS file (#174674) - add %check (#174674) automake15-1.5-14 ----------------- * Mon Dec 19 2005 Karsten Hopp 1.5-14 - fix insthook test: tail needs parameters '-n +NUMLINES' instead of '+NUMLINES' now * Fri Dec 09 2005 Jesse Keating - rebuilt caching-nameserver-7.3-4.FC5 ---------------------------- * Sun Dec 18 2005 Jason Vas Dias 7.3-4 - update for version differences FC-3 -> 4 -> 5 check-0.9.3-4.fc5 ----------------- * Mon Dec 19 2005 Warren Togami 0.9.2-4 - import into FC5 for gstreamer-0.10 * Fri Dec 02 2005 Tom "spot" Callaway 0.9.2-3 - enabled -fPIC to resolve bz 174313 * Sat Sep 17 2005 Tom "spot" Callaway 0.9.2-2 - get rid of the so file (not needed) - only make devel package cman-kernel-2.6.14.1-20051219.162641.FC5.3 ------------------------------------------ * Mon Dec 19 2005 Chris Feist - rebuilt cpufreq-utils-1:0.4-1.1.21 -------------------------- * Mon Dec 19 2005 Dave Jones - New upstream 0.4 release. cups-1:1.1.23-27 ---------------- * Mon Dec 19 2005 Tim Waugh 1:1.1.23-27 - Link pdftops with -z relro. cvs-1.11.21-2 ------------- * Wed Dec 14 2005 Martin Stransky 1.11.21-2 - fix for cvs diff with two -r switches (#18161) - pam patch (#48937) - CVS_RSH is set to ssh (#58699) cyrus-sasl-2.1.21-9 ------------------- * Mon Dec 19 2005 Nalin Dahyabhai 2.1.21-9 - use --as-needed to avoid linking dbconverter-2 with SQL libraries, which it doesn't use because it manipulates files directly (#173321) desktop-backgrounds-2.0-31 -------------------------- * Mon Dec 19 2005 Ray Strode 2.0-31 - replace default fedora background with new one from Diana Fong device-mapper-multipath-0.4.5-9.1 --------------------------------- * Mon Dec 19 2005 Benjamin Marzinski - 0.4.5-9.1 - added patch for fedora changes * Fri Dec 16 2005 Benjamin Marzinski - 0.4.5-9.0 - Updated to latest upstream source (t)_4_5_post52) dlm-kernel-2.6.14.1-20051219.162641.FC5.2 ----------------------------------------- * Mon Dec 19 2005 Chris Feist - rebuilt docbook-style-dsssl-1.79-3 -------------------------- * Mon Dec 19 2005 Tim Waugh 1.79-3 - Rebuilt. doxygen-1:1.4.5-3 ----------------- * Mon Dec 19 2005 Than Ngo 1.4.5-3 - apply patch to fix build problem with gcc-4.1 * Fri Dec 09 2005 Jesse Keating - rebuilt eclipse-1:3.1.1-1jpp_12fc ------------------------- * Mon Dec 19 2005 Igor Foox 3.1.1-1jpp_12fc - New version of launcher path (rh#175454). * Mon Dec 19 2005 Andrew Overholt 3.1.1-1jpp_11fc - Update patch for offline javadoc linking. - Rebuild with new gjdoc (rh#161147). evolution-2.5.3-1 ----------------- * Mon Dec 19 2005 David Malcolm - 2.5.3-1 - 2.5.3 - Updated patch 106 (evolution-2.2.2-commit-enter-on-calendar.patch) so that it still applies cleanly * Thu Dec 15 2005 Christopher Aillon 2.5.2-2 - Require nspr and nss instead of mozilla-nspr and mozilla-nss - Update no-gnome-common patch to work with standalone nss package evolution-connector-2.5.3-1 --------------------------- * Mon Dec 19 2005 David Malcolm - 2.5.3-1 - 2.5.3 - regenerate patch 200 - add patch to use correct marshalling code (patch 300) - dropped glob of etspec files evolution-data-server-1.5.3-2 ----------------------------- * Mon Dec 19 2005 David Malcolm - 1.5.3-2 - Update specfile and patch 5 (evolution-data-server-1.3.5-nspr_fix.patch) to use nss rather than mozilla-nss throughout * Mon Dec 19 2005 David Malcolm - 1.5.3-1 - 1.5.3 fedora-logos-1.1.35-1 --------------------- * Mon Dec 19 2005 Jeremy Katz - 1.1.35-1 - new images from dfong gdb-6.3.0.0-1.94 ---------------- * Mon Dec 19 2005 Alexandre Oliva 6.3.0.0-1.94 - Fix type-punning warnings issued by GCC 4.1. * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj * Thu Dec 01 2005 Jeff Johnston 6.3.0.0-1.93 - Bump up release number. gjdoc-0.7.7-1 ------------- * Mon Dec 19 2005 Andrew Overholt 0.7.7-1 - 0.7.7. gnbd-kernel-2.6.14.0-20051108.134753.FC5.12.2 --------------------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-libs-1:1.4.1.2.90-48 -------------------------- * Mon Dec 19 2005 Bill Nottingham - 1.1.4.1.2.90-48 - #175669 is fixed, rebuild with normal flags gnome-screensaver-0.0.22-3 -------------------------- * Mon Dec 19 2005 Matthias Clasen - 0.0.22-3 - add floaters lock dialog gtkhtml3-3.9.3-1 ---------------- * Mon Dec 19 2005 David Malcolm - 3.9.3-1 - 3.9.3 imake-1.0.0-2 ------------- * Mon Dec 19 2005 Than Ngo 1.0.0-2 - add some macros to fix problem in building of manpages * Sat Dec 17 2005 Mike A. Harris 1.0.0-1 - Updated all packages to version 1.0.0 from X11R7 RC4 - Added new lndir, gccmakedep tarballs. - Changed manpage dirs from man1x to man1 to match upstream RC4 default. - Removed all previous 'misc' patch, as we now pass --with-config-dir to configure to specify the location of the Imake config files. - Renamed imake patch to xorg-cf-files-1.0.0-ProjectRoot.patch as it did not patch imake at all. This should probably be changed to be a custom Red Hat host.def file that is added as a source line instead of randomly patching various files. * Fri Dec 09 2005 Jesse Keating 0.99.2-5.1 - rebuilt kernel-2.6.14-1.1776_FC5 ------------------------ * Mon Dec 19 2005 Dave Jones - 2.6.15-rc6 - Various ub stability improvements from Pete Zaitcev. - Update ACPICA. libselinux-1.29.2-2 ------------------- * Mon Dec 19 2005 Dan Walsh 1.29.2-2 - Move libselinux.so to base package libusb-0.1.10a-3 ---------------- * Mon Dec 19 2005 Tim Waugh 0.1.10a-3 - Rebuild. * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj * Mon Nov 21 2005 Tim Waugh 0.1.10a-2 - Build does not require xorg-x11-devel. Fixes rebuild problem (no more xorg-x11-devel package). libwvstreams-4.2.1-1 -------------------- * Mon Dec 19 2005 Harald Hoyer 4.2.1-1 - version 4.2.1 * Fri Dec 09 2005 Jesse Keating - rebuilt mcelog-1:0.5-1.13 ----------------- * Mon Dec 19 2005 Dave Jones - Update to upstream 0.5 mesa-6.4.1-1 ------------ * Sat Dec 17 2005 Mike A. Harris 6.4.1-1 - Updated MesaLib tarball to version 6.4.1 from Mesa project for X11R7 RC4. - Added pkgconfig dependency. - Updated "BuildRequires: libdrm-devel >= 2.0-1" - Added Obsoletes lines to all the subpackages to have cleaner upgrades. - Added mesa-6.4.1-amd64-assyntax-fix.patch to work around a build problem on AMD64, which is fixed in the 6.4 branch of Mesa CVS. - Conditionalize libOSMesa inclusion, and default to not including it for now. * Fri Dec 09 2005 Jesse Keating 6.4-5.1 - rebuilt * Sun Nov 20 2005 Jeremy Katz 6.4-5 - fix directory used for loading dri modules (#173679) - install dri drivers as executable so they get stripped (#173292) mkinitrd-5.0.15-1 ----------------- * Mon Dec 19 2005 Peter Jones - 5.0.15-1 - Don't open init's console with close-on-exec * Sun Dec 18 2005 Peter Jones - 5.0.14-1 - Remove vestigial loopback support. - Remove email addresses from man pages (which still need some work) nmap-2:3.95-1 ------------- * Mon Dec 19 2005 Harald Hoyer - 2:3.95-1 - version 3.95 * Fri Dec 09 2005 Jesse Keating - rebuilt openjade-1.3.2-22 ----------------- * Mon Dec 19 2005 Tim Waugh 1.3.2-22 - Fix SOC files. - Quieten scriptlets. * Mon Dec 19 2005 Tim Waugh 1.3.2-21 - Fix location of catalog. openoffice.org-1:2.0.1.1-1.2 ---------------------------- * Thu Dec 15 2005 Caolan McNamara - 1:2.0.1.1-1 - gcc#25199# fixed, drop bitfield patch - gcc#25389# fixed, drop jurt.nullpointer.patch - gcc#25426# identified, crash with jaxpapi patch - addressbooks a) evo1 addressbook removed, as only evo2 required b) mozilla addressbook removed, utterly useless c) evo2 ldap addressbook added to give some sort of ldap access d) patch wizard UI to show available addressbook backends - add openoffice.org-2.0.1.oooXXXXX.config_office.nss.patch - upstream cocks up their numbering pam_krb5-2.2.3-1 ---------------- * Mon Dec 19 2005 Nalin Dahyabhai - 2.2.3-1 - fix a compile problem caused by a missing #include (Jesse Keating) pango-1.11.1-2 -------------- * Mon Dec 19 2005 Matthias Clasen - 1.11.1-2 - BuildRequire cairo-devel perl-DBI-1.50-1 --------------- * Mon Dec 19 2005 Jason Vas Dias - 1.50-1 - upgrade to 1.50 perl-HTML-Parser-3.48-1 ----------------------- * Mon Dec 19 2005 Jason Vas Dias - 3.48-1 - upgrade to 3.48 perl-Net-DNS-0.55-1 ------------------- * Mon Dec 19 2005 Jason Vas Dias - 0.55-1 - Upgrade to upstream version 0.55 perl-XML-SAX-0.13-1 ------------------- * Mon Dec 19 2005 Jason Vas Dias - upgrade to 0.13 perl-XML-Twig-3.22-1 -------------------- * Mon Dec 19 2005 Jason Vas Dias - 3.22-1 - Update to 3.22 perl-libwww-perl-5.805-1 ------------------------ * Sun Dec 18 2005 Jason Vas Dias - 5.805-1 - Upgrade to 5.805-1 policycoreutils-1.29.2-3 ------------------------ * Wed Dec 14 2005 Dan Walsh 1.29.2-3 - Remove commands from genhomedircon for installer python-pyblock-0.9-1 -------------------- * Mon Dec 19 2005 Peter Jones - 0.9-1 - fix some backwards isinstance() calls that cause RaidSet.get_valid() to fail readahead-1:1.1-1.19.1 ---------------------- * Mon Dec 19 2005 Karel Zak - sync versioned gcc, firefox, openoffice.org, evolution dirs with FC5 selinux-policy-2.1.6-11 ----------------------- * Mon Dec 19 2005 Dan Walsh 2.1.6-11 - Add man pages * Fri Dec 16 2005 Dan Walsh 2.1.6-10 - Add enableaudit.pp * Fri Dec 16 2005 Dan Walsh 2.1.6-9 - Fix mls policy shared-mime-info-0.16.cvs20051219-1 ----------------------------------- * Mon Dec 19 2005 Matthias Clasen - 0.16.cvs20051219-1 - Newer cvs snapshot squid-7:2.5.STABLE12-3 ---------------------- * Mon Dec 19 2005 Martin Stransky 7:2.5.STABLE12-3 - fd-config.patch clean-up - SMB_BadFetch patch from upstream system-config-bind-4.0.0-33_FC5 ------------------------------- * Mon Dec 19 2005 Jason Vas Dias - 4.0.0-33 - fix bug 175420: traceback when named.conf included a nonexistent file - fix bug 176142: ship updated Serbian translation * Fri Dec 09 2005 Jesse Keating - rebuilt system-config-netboot-0.1.34-1 ------------------------------ * Mon Dec 19 2005 Jason Vas Dias - 0.1.34-1 - fix bug 174942: make diskless clients free initrd memory - fix bug 174941: fix mkdiskless syslog.conf typo: '*' -> '*.*' - fix bug 176144: ship updated translations systemtap-0.5.2-2 ----------------- * Mon Dec 19 2005 Roland McGrath - 0.5.2-2 - Rebuilt for devel * Mon Dec 19 2005 Roland McGrath - 0.5.2-1 - Fixed build with gcc 4.1, various tapset changes. * Wed Dec 07 2005 Roland McGrath - 0.5.1-1 - elfutils update, build changes transfig-1:3.2.4-13 ------------------- * Mon Dec 19 2005 Than Ngo 3.2.4-13 - fix build problem with modular X * Fri Dec 09 2005 Jesse Keating - rebuilt wvdial-1.54.0-5.2 ----------------- * Mon Dec 19 2005 Harald Hoyer - rebuilt xdoclet-0:1.2.2-2jpp_3fc ------------------------ * Mon Dec 19 2005 Archit Shah - 0:1.2.2-2jpp_3fc - Remove use of external javadoc URLs from javadoc task. * Fri Dec 09 2005 Jesse Keating - 0:1.2.2-2jpp_2fc - rebuilt xorg-x11-utils-1.0.0-1 ---------------------- * Sat Dec 17 2005 Mike A. Harris 1.0.0-1 - Updated all tarballs to version 1.0.0 from X11R7 RC4. - Changed manpage dir from man1x to man1 to match upstream RC4 default. - Moved all app-defaults files from _libdir to _datadir xorg-x11-xbitmaps-1.0.0-1 ------------------------- * Sat Dec 17 2005 Mike A. Harris 1.0.0-1 - Updated to xbitmaps 1.0.0 from X11R7 RC4. xorg-x11-xkb-utils-1.0.0-1 -------------------------- * Sat Dec 17 2005 Mike A. Harris 1.0.0-1 - Updated all apps to version 1.0.0 from X11R7 RC4. - Changed manpage dir from man1x to man1 to match upstream default. xorg-x11-xkbdata-1.0.0-1 ------------------------ Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.2.i686 requires /lib/modules/2.6.14-1.1775_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.2.i686 requires kernel = 0:2.6.14-1.1775_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.2.i686 requires kernel-smp = 0:2.6.14-1.1775_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.2.i686 requires /lib/modules/2.6.14-1.1775_FC5smp cman-kernel - 2.6.14.1-20051219.162641.FC5.3.i686 requires /lib/modules/2.6.14-1.1775_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.3.i686 requires kernel = 0:2.6.14-1.1775_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.3.i686 requires kernel-smp = 0:2.6.14-1.1775_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.3.i686 requires /lib/modules/2.6.14-1.1775_FC5smp control-center - 1:2.13.3-1.i386 requires libedataserver-1.2.so.4 dlm-kernel - 2.6.14.1-20051219.162641.FC5.2.i686 requires /lib/modules/2.6.14-1.1775_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.2.i686 requires kernel = 0:2.6.14-1.1775_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.2.i686 requires kernel-smp = 0:2.6.14-1.1775_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.2.i686 requires /lib/modules/2.6.14-1.1775_FC5smp evolution-webcal - 2.4.1-1.1.i386 requires libedataserver-1.2.so.4 gaim - 1:1.5.0-9.fc5.1.i386 requires libedataserver-1.2.so.4 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.2.i686 requires /lib/modules/2.6.14-1.1775_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.2.i686 requires kernel = 0:2.6.14-1.1775_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.2.i686 requires kernel-smp = 0:2.6.14-1.1775_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.2.i686 requires /lib/modules/2.6.14-1.1775_FC5smp gnome-panel - 2.13.3-1.i386 requires libedataserver-1.2.so.4 gnome-python2-libgtop2 - 2.12.1-7.1.i386 requires libgtop-2.0.so.5 gnomemeeting - 1.2.3-1.i386 requires libedataserver-1.2.so.4 jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 nautilus-sendto - 0.4-5.1.i386 requires libedataserver-1.2.so.4 Broken deps for ia64 ---------------------------------------------------------- control-center - 1:2.13.3-1.ia64 requires libedataserver-1.2.so.4()(64bit) evolution-webcal - 2.4.1-1.1.ia64 requires libedataserver-1.2.so.4()(64bit) gaim - 1:1.5.0-9.fc5.1.ia64 requires libedataserver-1.2.so.4()(64bit) gnome-panel - 2.13.3-1.ia64 requires libedataserver-1.2.so.4()(64bit) gnome-python2-libgtop2 - 2.12.1-7.1.ia64 requires libgtop-2.0.so.5()(64bit) gnomemeeting - 1.2.3-1.ia64 requires libedataserver-1.2.so.4()(64bit) jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) nautilus-sendto - 0.4-5.1.ia64 requires libedataserver-1.2.so.4()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 control-center - 1:2.13.3-1.ppc requires libedataserver-1.2.so.4 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 evolution-webcal - 2.4.1-1.1.ppc requires libedataserver-1.2.so.4 gaim - 1:1.5.0-9.fc5.1.ppc requires libedataserver-1.2.so.4 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 gnome-panel - 2.13.3-1.ppc requires libedataserver-1.2.so.4 gnome-python2-libgtop2 - 2.12.1-7.1.ppc requires libgtop-2.0.so.5 gnomemeeting - 1.2.3-1.ppc requires libedataserver-1.2.so.4 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 nautilus-sendto - 0.4-5.1.ppc requires libedataserver-1.2.so.4 Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 control-center - 1:2.13.3-1.ppc64 requires libedataserver-1.2.so.4()(64bit) dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi evolution-webcal - 2.4.1-1.1.ppc64 requires libedataserver-1.2.so.4()(64bit) gaim - 1:1.5.0-9.fc5.1.ppc64 requires libedataserver-1.2.so.4()(64bit) gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 gnome-panel - 2.13.3-1.ppc64 requires libedataserver-1.2.so.4()(64bit) gnome-python2-libgtop2 - 2.12.1-7.1.ppc64 requires libgtop-2.0.so.5()(64bit) gnomemeeting - 1.2.3-1.ppc64 requires libedataserver-1.2.so.4()(64bit) jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) nautilus-sendto - 0.4-5.1.ppc64 requires libedataserver-1.2.so.4()(64bit) Broken deps for s390 ---------------------------------------------------------- control-center - 1:2.13.3-1.s390 requires libedataserver-1.2.so.4 evolution-webcal - 2.4.1-1.1.s390 requires libedataserver-1.2.so.4 gaim - 1:1.5.0-9.fc5.1.s390 requires libedataserver-1.2.so.4 gnome-panel - 2.13.3-1.s390 requires libedataserver-1.2.so.4 gnome-python2-libgtop2 - 2.12.1-7.1.s390 requires libgtop-2.0.so.5 gnomemeeting - 1.2.3-1.s390 requires libedataserver-1.2.so.4 jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 nautilus-sendto - 0.4-5.1.s390 requires libedataserver-1.2.so.4 systemtap - 0.5.2-2.s390 requires kernel >= 0:2.6.9-11 systemtap - 0.5.2-2.s390 requires kernel-devel Broken deps for s390x ---------------------------------------------------------- control-center - 1:2.13.3-1.s390x requires libedataserver-1.2.so.4()(64bit) evolution-webcal - 2.4.1-1.1.s390x requires libedataserver-1.2.so.4()(64bit) gaim - 1:1.5.0-9.fc5.1.s390x requires libedataserver-1.2.so.4()(64bit) gnome-panel - 2.13.3-1.s390x requires libedataserver-1.2.so.4()(64bit) gnome-panel - 2.13.3-1.s390 requires libedataserver-1.2.so.4 gnome-python2-libgtop2 - 2.12.1-7.1.s390x requires libgtop-2.0.so.5()(64bit) gnomemeeting - 1.2.3-1.s390x requires libedataserver-1.2.so.4()(64bit) jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) libgnome-java - 2.12.0-2.s390x requires libgcj.so.6()(64bit) libgnome-java - 2.12.0-2.s390x requires libcairojava-1.0.so()(64bit) libgtk-java - 2.8.0-7.s390x requires libgcj.so.6()(64bit) libvte-java - 0.11.11-6.3.s390x requires libcairojava-1.0.so()(64bit) nautilus-sendto - 0.4-5.1.s390x requires libedataserver-1.2.so.4()(64bit) systemtap - 0.5.2-2.s390x requires kernel >= 0:2.6.9-11 systemtap - 0.5.2-2.s390x requires kernel-devel Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.2.x86_64 requires /lib/modules/2.6.14-1.1775_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.2.x86_64 requires kernel = 0:2.6.14-1.1775_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.3.x86_64 requires /lib/modules/2.6.14-1.1775_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.3.x86_64 requires kernel = 0:2.6.14-1.1775_FC5 control-center - 1:2.13.3-1.x86_64 requires libedataserver-1.2.so.4()(64bit) dlm-kernel - 2.6.14.1-20051219.162641.FC5.2.x86_64 requires /lib/modules/2.6.14-1.1775_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.2.x86_64 requires kernel = 0:2.6.14-1.1775_FC5 evolution-webcal - 2.4.1-1.1.x86_64 requires libedataserver-1.2.so.4()(64bit) gaim - 1:1.5.0-9.fc5.1.x86_64 requires libedataserver-1.2.so.4()(64bit) gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.2.x86_64 requires /lib/modules/2.6.14-1.1775_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.2.x86_64 requires kernel = 0:2.6.14-1.1775_FC5 gnome-panel - 2.13.3-1.i386 requires libedataserver-1.2.so.4 gnome-panel - 2.13.3-1.x86_64 requires libedataserver-1.2.so.4()(64bit) gnome-python2-libgtop2 - 2.12.1-7.1.x86_64 requires libgtop-2.0.so.5()(64bit) gnomemeeting - 1.2.3-1.x86_64 requires libedataserver-1.2.so.4()(64bit) jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) nautilus-sendto - 0.4-5.1.x86_64 requires libedataserver-1.2.so.4()(64bit) From gianluca.cecchi at gmail.com Tue Dec 20 08:40:49 2005 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Tue, 20 Dec 2005 09:40:49 +0100 Subject: scim-libs not signed error when using yum?? In-Reply-To: <43A7A563.2090101@redhat.com> References: <561c252c0512192149p22498ad0v@mail.gmail.com> <43A7A563.2090101@redhat.com> Message-ID: <561c252c0512200040w47d4a6b4r@mail.gmail.com> For Jens: > > Please set "gpgcheck=0" in the appropriate repos file in > "/etc/yum.repos.d/". > > Jens > I already had gpgcheck=0 in all files under yum.repos.d directory. But the error remained. It seems that to get yum working with the "localupdate" flag it is also necessary to change the /etc/yum.conf file setting gpgcheck=0 there. After changing it, it worked out. Thanks for the suggestion about the way to follow. The doubt about correct use of "localupdate" still remains for a production system yet.... For Raul: >>Not sure what you mean here. I mean that I use rsync command on one system; then in the other one (virtual machine) I mount the RPMS directory via nfs and use yum using the flag "localupdate" and specifying *rpm for all packages contained. In this way yum should use local rpm files without downloading, and download eventually only files that are missing from the local *rpm list and that are necessary for dependencies. Gianluca -------------- next part -------------- An HTML attachment was scrubbed... URL: From caolanm at redhat.com Tue Dec 20 08:55:25 2005 From: caolanm at redhat.com (Caolan McNamara) Date: Tue, 20 Dec 2005 08:55:25 +0000 Subject: OO x86_64 status? In-Reply-To: <1135037479.17062.1.camel@gilboa-home-dev.localhost> References: <1135037479.17062.1.camel@gilboa-home-dev.localhost> Message-ID: <1135068926.2695.73.camel@localhost.localdomain> On Tue, 2005-12-20 at 02:11 +0200, Gilboa Davara wrote: > Hello all, > > What are the chances of having a fully 64bit Open-Office ready for FC5 > release? None > Does anyone know if the OO.org team managed to stabilize the 64bit > builds? Somewhat, but progress continues. Currently the rather vast 64bit patch set is being split into specific targeted patches and applied one at a time to the trunk. C. From i at stingr.net Tue Dec 20 08:56:57 2005 From: i at stingr.net (Paul P Komkoff Jr) Date: Tue, 20 Dec 2005 11:56:57 +0300 Subject: Too much time wasted installing fedora on raid1 In-Reply-To: <1135026753.2947.23.camel@laptopd505.fenrus.org> References: <20051219201653.GU1556@stingr.net> <1135026753.2947.23.camel@laptopd505.fenrus.org> Message-ID: <20051220085657.GW1556@stingr.net> Replying to Arjan van de Ven: > > So, to boot without changing bios settings back and forth (or without > > disabling 1st disk drive by any other means) it is nesessary to wait > > while md1 raid1 resyncs, which can be as long as 2 hours (250GB HDD). > > I'm pretty sure that anaconda at some point deliberately did things to > avoid that sync. So I suspect it got reenabled for a good reason... There's nothing wrong in sync itself, but the order. If /boot will be synched first then it will be safe to reboot as soon as actual installation is complete (and root volume reconstruction can happen later) -- Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key This message represents the official view of the voices in my head From m.f.h at web.de Tue Dec 20 09:02:01 2005 From: m.f.h at web.de (Marcus Hartig) Date: Tue, 20 Dec 2005 10:02:01 +0100 Subject: gnome / xorg / nautilus / cairo / freetype desktop rendering slow Message-ID: <43A7C889.8010904@web.de> Hello, I do not know for which package to write a bug, cause... I've a very bad and slow desktop rendering speed with the latest GNOME and nautilus rawhide. Moving a little gnome-terminal window is bumpy, when I switch to another workspace, the whole gnome desktop gets freezed, only the background is displayed, no icons and a delay for ca. 3-5 sec comes to the screen, where i cannot do anything with a mouse click response. I had this in the past only with the firefox pop-ups, but now with the whole gnome desktop. This happened with the nv (xorg) and the nVidia GFX driver, with agpgart or the nvida nvagp, with Fedora rawhide kernel and a vanilla, but *only* under the gnome desktop. With KDE all is fast and smooth, except firefox and thunderbird is again slow rendering fonts and bad displayed. I've tried to turn off sub-pixel-rendering for my Dell notebook with a Geforce 6800 Go, played with hinting, then with the bytecode-interpreter enabled, but under gnome all is slow again. Then I've tried to compare ftbench benchs, no reason found. Then x11perf, also no really spped diffenrence found. All logs show no errors. Anybody know, what the reason can be? Is it cairo, the font rendering from freetype, gtk2 or nautilus? I really do not know, where to go ahead. :-( Marcus From rodd at clarkson.id.au Tue Dec 20 09:12:00 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Tue, 20 Dec 2005 20:12:00 +1100 Subject: gnome / xorg / nautilus / cairo / freetype desktop rendering slow In-Reply-To: <43A7C889.8010904@web.de> References: <43A7C889.8010904@web.de> Message-ID: <1135069920.3149.4.camel@localhost.localdomain> On Tue, 2005-12-20 at 10:02 +0100, Marcus Hartig wrote: > Hello, > > I do not know for which package to write a bug, cause... > > I've a very bad and slow desktop rendering speed with the latest GNOME > and nautilus rawhide. Moving a little gnome-terminal window is bumpy, > when I switch to another workspace, the whole gnome desktop gets > freezed, only the background is displayed, no icons and a delay for ca. > 3-5 sec comes to the screen, where i cannot do anything with a mouse > click response. I had this in the past only with the firefox pop-ups, > but now with the whole gnome desktop. > > This happened with the nv (xorg) and the nVidia GFX driver, with agpgart > or the nvida nvagp, with Fedora rawhide kernel and a vanilla, but *only* > under the gnome desktop. With KDE all is fast and smooth, except firefox > and thunderbird is again slow rendering fonts and bad displayed. > > I've tried to turn off sub-pixel-rendering for my Dell notebook with a > Geforce 6800 Go, played with hinting, then with the bytecode-interpreter > enabled, but under gnome all is slow again. > Then I've tried to compare ftbench benchs, no reason found. Then > x11perf, also no really spped diffenrence found. All logs show no errors. > > Anybody know, what the reason can be? Is it cairo, the font rendering > from freetype, gtk2 or nautilus? I really do not know, where to go > ahead. :-( Hmmm, I've noticed this too, and I'm also using the nv driver with and GeForce 6800 Go chipset in a Dell laptop. This only happened very recently (maybe last nights update). I'm also unable to get better than 1600x1200 resolution on my 1920x1200 screen. R. -- "It's a fine line between denial and faith. It's much better on my side" From arjan at fenrus.demon.nl Tue Dec 20 09:46:18 2005 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Tue, 20 Dec 2005 10:46:18 +0100 Subject: Too much time wasted installing fedora on raid1 In-Reply-To: <20051220085657.GW1556@stingr.net> References: <20051219201653.GU1556@stingr.net> <1135026753.2947.23.camel@laptopd505.fenrus.org> <20051220085657.GW1556@stingr.net> Message-ID: <1135071978.2952.8.camel@laptopd505.fenrus.org> On Tue, 2005-12-20 at 11:56 +0300, Paul P Komkoff Jr wrote: > Replying to Arjan van de Ven: > > > So, to boot without changing bios settings back and forth (or without > > > disabling 1st disk drive by any other means) it is nesessary to wait > > > while md1 raid1 resyncs, which can be as long as 2 hours (250GB HDD). > > > > I'm pretty sure that anaconda at some point deliberately did things to > > avoid that sync. So I suspect it got reenabled for a good reason... > > There's nothing wrong in sync itself, but the order. > If /boot will be synched first then it will be safe to reboot as soon > as actual installation is complete (and root volume reconstruction can > happen later) well... if the root is brand spanking new.. why would it need a sync? From fedora at camperquake.de Tue Dec 20 10:13:03 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 20 Dec 2005 11:13:03 +0100 Subject: Too much time wasted installing fedora on raid1 In-Reply-To: <1135071978.2952.8.camel@laptopd505.fenrus.org> References: <20051219201653.GU1556@stingr.net> <1135026753.2947.23.camel@laptopd505.fenrus.org> <20051220085657.GW1556@stingr.net> <1135071978.2952.8.camel@laptopd505.fenrus.org> Message-ID: <20051220101303.GB23000@ryoko.camperquake.de> On Tue, Dec 20, 2005 at 10:46:18AM +0100, Arjan van de Ven wrote: > well... if the root is brand spanking new.. why would it need a sync? Because it _is_ brand spanking new (and thus unclean from a RAID point of view)? From arjan at fenrus.demon.nl Tue Dec 20 10:19:15 2005 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Tue, 20 Dec 2005 11:19:15 +0100 Subject: Too much time wasted installing fedora on raid1 In-Reply-To: <20051220101303.GB23000@ryoko.camperquake.de> References: <20051219201653.GU1556@stingr.net> <1135026753.2947.23.camel@laptopd505.fenrus.org> <20051220085657.GW1556@stingr.net> <1135071978.2952.8.camel@laptopd505.fenrus.org> <20051220101303.GB23000@ryoko.camperquake.de> Message-ID: <1135073956.2952.10.camel@laptopd505.fenrus.org> On Tue, 2005-12-20 at 11:13 +0100, Ralf Ertzinger wrote: > On Tue, Dec 20, 2005 at 10:46:18AM +0100, Arjan van de Ven wrote: > > > well... if the root is brand spanking new.. why would it need a sync? > > Because it _is_ brand spanking new (and thus unclean from a RAID point > of view)? but.. it might as well be marked clean. there's no information in never-used parts of the disk after all... so why sync it instead of pretending it's synced perfectly fine.... From kms at passback.co.uk Tue Dec 20 10:20:35 2005 From: kms at passback.co.uk (Keith Sharp) Date: Tue, 20 Dec 2005 10:20:35 +0000 Subject: booting notebooks vs. suspend (was Re: boot faster) In-Reply-To: <20051219162103.GG31712@ryoko.camperquake.de> References: <1134921889.11021.47.camel@localhost.localdomain> <604aa7910512180940v3884a78byfc5445eb0e7dbed2@mail.gmail.com> <1134956408.11021.69.camel@localhost.localdomain> <43A6A655.6080400@redhat.com> <43A6B8C7.5080008@mesias.co.uk> <1135008339.28062.0.camel@yoda.loki.me> <1135008807.14566.38.camel@gilboa-work-dev> <20051219162103.GG31712@ryoko.camperquake.de> Message-ID: <1135074035.23619.10.camel@animal.passback.co.uk> On Mon, 2005-12-19 at 17:21 +0100, Ralf Ertzinger wrote: > On Mon, Dec 19, 2005 at 06:13:27PM +0200, Gilboa Davara wrote: > > Umm... I rarely boot my machines (once in a couple of months), but I'd > > venture to guess that if suspend-resume was bullet-proof, people would > > have rebooted their machine only in the cases above, which are pretty > > rare events for most Linux users. > > Plus, I might be wrong here, but doesn't suspend to disk theoretically > > allows you to suspend, switch to Windows (*spit!), and pick up where you > > left once you switch back to Linux? > > As long as windows leaves the Linux partitions alone that should work. I can confirm that this works. You can even suspend (hibernate) in Windows as well :-) Keith. From i at stingr.net Tue Dec 20 10:26:29 2005 From: i at stingr.net (Paul P Komkoff Jr) Date: Tue, 20 Dec 2005 13:26:29 +0300 Subject: Too much time wasted installing fedora on raid1 In-Reply-To: <1135073956.2952.10.camel@laptopd505.fenrus.org> References: <20051219201653.GU1556@stingr.net> <1135026753.2947.23.camel@laptopd505.fenrus.org> <20051220085657.GW1556@stingr.net> <1135071978.2952.8.camel@laptopd505.fenrus.org> <20051220101303.GB23000@ryoko.camperquake.de> <1135073956.2952.10.camel@laptopd505.fenrus.org> Message-ID: <20051220102629.GX1556@stingr.net> Replying to Arjan van de Ven: > > Because it _is_ brand spanking new (and thus unclean from a RAID point > > of view)? > > but.. it might as well be marked clean. there's no information in > never-used parts of the disk after all... so why sync it instead of > pretending it's synced perfectly fine.... raid1 means that contents of both mirrors are exactly the same. Just after creation, this is obviously not true. Linux MD implementation solving this problem by synching it. Other solution may be to store list of written blocks and do something with this, but, I think this isn't reliable/scalable. Anyway, as I said previously, root volume reconstruction can happily continue after firstboot (and second boot too), but inconsistency in /boot making system unbootable. -- Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key This message represents the official view of the voices in my head From m.f.h at web.de Tue Dec 20 11:00:33 2005 From: m.f.h at web.de (Marcus Hartig) Date: Tue, 20 Dec 2005 12:00:33 +0100 Subject: rawhide report: 20051220 changes In-Reply-To: <200512200819.jBK8JoHM013990@porkchop.devel.redhat.com> References: <200512200819.jBK8JoHM013990@porkchop.devel.redhat.com> Message-ID: <43A7E451.5030501@web.de> > desktop-backgrounds-2.0-31 > -------------------------- > * Mon Dec 19 2005 Ray Strode 2.0-31 > - replace default fedora background with new one > from Diana Fong Wow! That is a cool background....the woman has a good taste. This fedora picture in grub and in rhgb in future? GDM? Marcus From sundaram at redhat.com Tue Dec 20 11:03:06 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Tue, 20 Dec 2005 16:33:06 +0530 Subject: rawhide report: 20051220 changes In-Reply-To: <43A7E451.5030501@web.de> References: <200512200819.jBK8JoHM013990@porkchop.devel.redhat.com> <43A7E451.5030501@web.de> Message-ID: <43A7E4EA.9020202@redhat.com> Marcus Hartig wrote: > >> desktop-backgrounds-2.0-31 >> -------------------------- >> * Mon Dec 19 2005 Ray Strode 2.0-31 >> - replace default fedora background with new one >> from Diana Fong > > > Wow! That is a cool background....the woman has a good taste. > > This fedora picture in grub and in rhgb in future? GDM? Patience is a virtue. Isnt it? ;-) regards Rahul From dwmw2 at infradead.org Tue Dec 20 11:07:53 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 20 Dec 2005 11:07:53 +0000 Subject: rawhide report: 20051220 changes In-Reply-To: <43A7E451.5030501@web.de> References: <200512200819.jBK8JoHM013990@porkchop.devel.redhat.com> <43A7E451.5030501@web.de> Message-ID: <1135076873.4066.2.camel@pmac.infradead.org> On Tue, 2005-12-20 at 12:00 +0100, Marcus Hartig wrote: > Wow! That is a cool background....the woman has a good taste. > This fedora picture in grub and in rhgb in future? GDM? How can you tell? I can't log in to X successfully at all... I just get errors and completely empty dialog box with the title 'Question' ... https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=122371 -- dwmw2 From sundaram at redhat.com Tue Dec 20 11:10:44 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Tue, 20 Dec 2005 16:40:44 +0530 Subject: rawhide report: 20051220 changes In-Reply-To: <1135076873.4066.2.camel@pmac.infradead.org> References: <200512200819.jBK8JoHM013990@porkchop.devel.redhat.com> <43A7E451.5030501@web.de> <1135076873.4066.2.camel@pmac.infradead.org> Message-ID: <43A7E6B4.8000700@redhat.com> David Woodhouse wrote: >On Tue, 2005-12-20 at 12:00 +0100, Marcus Hartig wrote: > > >>Wow! That is a cool background....the woman has a good taste. >>This fedora picture in grub and in rhgb in future? GDM? >> >> > >How can you tell? I can't log in to X successfully at all... I just get >errors and completely empty dialog box with the title 'Question' ... >https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=122371 > > > Works much slower but does lunch eventually on my system. Once logged in I dont get any error messages at all. regards Rahul From denis at poolshark.org Tue Dec 20 11:24:07 2005 From: denis at poolshark.org (Denis Leroy) Date: Tue, 20 Dec 2005 03:24:07 -0800 Subject: Too much time wasted installing fedora on raid1 In-Reply-To: <20051220102629.GX1556@stingr.net> References: <20051219201653.GU1556@stingr.net> <1135026753.2947.23.camel@laptopd505.fenrus.org> <20051220085657.GW1556@stingr.net> <1135071978.2952.8.camel@laptopd505.fenrus.org> <20051220101303.GB23000@ryoko.camperquake.de> <1135073956.2952.10.camel@laptopd505.fenrus.org> <20051220102629.GX1556@stingr.net> Message-ID: <43A7E9D7.3030501@poolshark.org> Paul P Komkoff Jr wrote: > Replying to Arjan van de Ven: > >>>Because it _is_ brand spanking new (and thus unclean from a RAID point >>>of view)? >> >>but.. it might as well be marked clean. there's no information in >>never-used parts of the disk after all... so why sync it instead of >>pretending it's synced perfectly fine.... > > > raid1 means that contents of both mirrors are exactly the same. Just > after creation, this is obviously not true. Linux MD implementation > solving this problem by synching it. No but if you plan to format the partition right after creating the RAID, which is usually the case, you can force the raid clean: sectors will only be written (and written clean to both disks), never read first. Well at least on paper. From m.f.h at web.de Tue Dec 20 11:24:18 2005 From: m.f.h at web.de (Marcus Hartig) Date: Tue, 20 Dec 2005 12:24:18 +0100 Subject: rawhide report: 20051220 changes In-Reply-To: <1135076873.4066.2.camel@pmac.infradead.org> References: <200512200819.jBK8JoHM013990@porkchop.devel.redhat.com> <43A7E451.5030501@web.de> <1135076873.4066.2.camel@pmac.infradead.org> Message-ID: <43A7E9E2.6020508@web.de> David Woodhouse wrote: > How can you tell? I can't log in to X successfully at all... I haven't logged out... only updated and the bg changed... ;) > errors and completely empty dialog box with the title 'Question' ... > https://bugzilla.redhat.com/bugzilla/attachment.cgi?id=122371 I do not use gnome anymore with my slow rendering problems. Marcus From paul at city-fan.org Tue Dec 20 12:30:07 2005 From: paul at city-fan.org (Paul Howarth) Date: Tue, 20 Dec 2005 12:30:07 +0000 Subject: bittorrent in core? what frontend? In-Reply-To: References: <1134662961.28842.128.camel@greebo> <20051215202126.GA4210@devserv.devel.redhat.com> <1134721846.28842.166.camel@greebo> <20051217070856.GD24500@devserv.devel.redhat.com> <1134979247.28842.210.camel@greebo> <43A6E55D.9070303@city-fan.org> Message-ID: <43A7F94F.902@city-fan.org> Sean wrote: > On Mon, December 19, 2005 11:52 am, Paul Howarth said: > > >>I've pushed an update to 4.2.2 earlier today. I'm not sure about >>disabling the "updated version" check. On the one hand people should >>only be updating the package using RPM, but on the other hand the alert >>will let them know that a new version is available, and that might >>prompt them to run "yum update" if they don't have automatic updates >>turned on. > > > Great. I must have just upgraded a bit before your push. Which version of bittorrent are you using? Looking at the code, it looks to me that the update-checking code is only enabled for Windows and OSX unless the DEBUG flag is set. > As for the auto-update feature, the user already has utilities that notify > them when an update is available; why a special update notice for this one > little app? Also, a naive user might not understand that they should > wait for the update to appear via their normal update process. Also, an > admin might turn off the regular auto-updating for users and not know he > has to do something special to shut off this one app. > > All in all, there are a lot of reasons that having a separate update > notification available for this app. I now share the view that the new version check should be disabled. However, I've so far been unable to provoke the client into telling me about a new version, even though I've got an old one installed, so it's difficult to test any patch I make (which will certainly need testing since I'm not a python programmer). Paul. From dwmw2 at infradead.org Tue Dec 20 12:35:17 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 20 Dec 2005 12:35:17 +0000 Subject: Too much time wasted installing fedora on raid1 In-Reply-To: <1135073956.2952.10.camel@laptopd505.fenrus.org> References: <20051219201653.GU1556@stingr.net> <1135026753.2947.23.camel@laptopd505.fenrus.org> <20051220085657.GW1556@stingr.net> <1135071978.2952.8.camel@laptopd505.fenrus.org> <20051220101303.GB23000@ryoko.camperquake.de> <1135073956.2952.10.camel@laptopd505.fenrus.org> Message-ID: <1135082117.3154.5.camel@localhost.localdomain> On Tue, 2005-12-20 at 11:19 +0100, Arjan van de Ven wrote: > but.. it might as well be marked clean. there's no information in > never-used parts of the disk after all... so why sync it instead of > pretending it's synced perfectly fine.... Because it's RAID, and it doesn't know anything about the file system -- it's just trying na?vely to keep the _block_ device synchronised, without any of that helpful knowledge about which blocks the file system actually cares about, or might have touched since the array was last known to be consistent. This is one of the reasons I believe RAID is the wrong solution; a better option would be to have the file system natively handle redundancy across block devices, rather than having two separate layers each of which know nothing about the other. Imagine a 'RAID resync' which only needed to resync those blocks which the file system's journal says have been modified since the state was last consistent... -- dwmw2 From jfrieben at freesurf.fr Tue Dec 20 12:55:06 2005 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Tue, 20 Dec 2005 13:55:06 +0100 (CET) Subject: rawhide report: 20051220 changes In-Reply-To: <43A7E451.5030501@web.de> References: <43A7E451.5030501@web.de> Message-ID: <17971.194.94.224.254.1135083306.squirrel@jose.freesurf.fr> How perception differs ...! I do find the new "grub" image and the default background very unpleasant. Strange colour hues and way too bright, when the previous Fedora default background was much too dark. One can barely read the icon subtitles. Very eye straining! I strongly recommend to adopt a different, decent and eye friendly colour scheme as in RHEl4. Joachim > >> desktop-backgrounds-2.0-31 >> -------------------------- >> * Mon Dec 19 2005 Ray Strode 2.0-31 >> - replace default fedora background with new one >> from Diana Fong > > Wow! That is a cool background....the woman has a good taste. > > This fedora picture in grub and in rhgb in future? GDM? > > Marcus > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From nicolas.mailhot at laposte.net Tue Dec 20 13:06:05 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 20 Dec 2005 14:06:05 +0100 (CET) Subject: Too much time wasted installing fedora on raid1 In-Reply-To: <1135082117.3154.5.camel@localhost.localdomain> References: <20051219201653.GU1556@stingr.net> <1135026753.2947.23.camel@laptopd505.fenrus.org> <20051220085657.GW1556@stingr.net> <1135071978.2952.8.camel@laptopd505.fenrus.org> <20051220101303.GB23000@ryoko.camperquake.de> <1135073956.2952.10.camel@laptopd505.fenrus.org> <1135082117.3154.5.camel@localhost.localdomain> Message-ID: <36717.192.54.193.25.1135083965.squirrel@rousalka.dyndns.org> On Mar 20 d?cembre 2005 13:35, David Woodhouse wrote: > On Tue, 2005-12-20 at 11:19 +0100, Arjan van de Ven wrote: >> but.. it might as well be marked clean. there's no information in >> never-used parts of the disk after all... so why sync it instead of >> pretending it's synced perfectly fine.... > > Because it's RAID, and it doesn't know anything about the file system -- > it's just trying na?vely to keep the _block_ device synchronised, > without any of that helpful knowledge about which blocks the file system > actually cares about, or might have touched since the array was last > known to be consistent. I don't know how anaconda handles it but the default raid IO limits are very conservative (optimized for background work on a live system) On a system being created it's probably a better idea to tell the raid system to pump as much blocks as possible, since this is a blocking op in this context and we don't care about anything else. -- Nicolas Mailhot From dwmw2 at infradead.org Tue Dec 20 13:20:20 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Tue, 20 Dec 2005 13:20:20 +0000 Subject: Too much time wasted installing fedora on raid1 In-Reply-To: <36717.192.54.193.25.1135083965.squirrel@rousalka.dyndns.org> References: <20051219201653.GU1556@stingr.net> <1135026753.2947.23.camel@laptopd505.fenrus.org> <20051220085657.GW1556@stingr.net> <1135071978.2952.8.camel@laptopd505.fenrus.org> <20051220101303.GB23000@ryoko.camperquake.de> <1135073956.2952.10.camel@laptopd505.fenrus.org> <1135082117.3154.5.camel@localhost.localdomain> <36717.192.54.193.25.1135083965.squirrel@rousalka.dyndns.org> Message-ID: <1135084820.4066.31.camel@pmac.infradead.org> On Tue, 2005-12-20 at 14:06 +0100, Nicolas Mailhot wrote: > I don't know how anaconda handles it but the default raid IO limits are > very conservative (optimized for background work on a live system) > > On a system being created it's probably a better idea to tell the raid > system to pump as much blocks as possible, since this is a blocking op in > this context and we don't care about anything else. I think you miss the point. On a file system which is being created, the bandwidth limits _ought_ to be fairly much irrelevant. The file system is _empty_, and the total amount of I/O to create an empty RAID-1 ought to be almost exactly the same amount of I/O which it takes just to run 'mkfs' twice. The blocks which aren't yet used by the filesystem don't matter; you shouldn't need to sync their contents. RAID is just a hack which hides the redundancy from the file system; the kind of thing we always used to have to do for DOS compatibility so that we could provide an INT 13h handler and have it 'just work'. It's much the same reasoning which led to the built-in 'translation layers' on cheap CF cards and USB sticks which so often eat your data and which have a tendency to use up their limited lifetime in copying obsolete sectors belonging to deleted files around on the underlying medium. We don't _need_ that kind of layering in Linux. Have a library of functions which can be used for such redundancy, by all means -- but don't just make RAID pretend to be a 'standard' block device and prevent all possibility of sharing knowledge between the file system and the layer providing the redundancy. That's just insane. -- dwmw2 From i at stingr.net Tue Dec 20 13:45:26 2005 From: i at stingr.net (Paul P Komkoff Jr) Date: Tue, 20 Dec 2005 16:45:26 +0300 Subject: Too much time wasted installing fedora on raid1 In-Reply-To: <1135084820.4066.31.camel@pmac.infradead.org> References: <20051219201653.GU1556@stingr.net> <1135026753.2947.23.camel@laptopd505.fenrus.org> <20051220085657.GW1556@stingr.net> <1135071978.2952.8.camel@laptopd505.fenrus.org> <20051220101303.GB23000@ryoko.camperquake.de> <1135073956.2952.10.camel@laptopd505.fenrus.org> <1135082117.3154.5.camel@localhost.localdomain> <36717.192.54.193.25.1135083965.squirrel@rousalka.dyndns.org> <1135084820.4066.31.camel@pmac.infradead.org> Message-ID: <20051220134526.GZ1556@stingr.net> Replying to David Woodhouse: > RAID is just a hack which hides the redundancy from the file system; the > kind of thing we always used to have to do for DOS compatibility so that > we could provide an INT 13h handler and have it 'just work'. It's much > the same reasoning which led to the built-in 'translation layers' on > cheap CF cards and USB sticks which so often eat your data and which > have a tendency to use up their limited lifetime in copying obsolete > sectors belonging to deleted files around on the underlying medium. > > We don't _need_ that kind of layering in Linux. Have a library of > functions which can be used for such redundancy, by all means -- but > don't just make RAID pretend to be a 'standard' block device and prevent > all possibility of sharing knowledge between the file system and the > layer providing the redundancy. That's just insane. Well, everything you said habove is correct. But I've yet seen any "redundant block device filesystem" project anywhere. Anybody willing to start it? Meanwhile, maybe we can fix md sync ordering? :))) -- Paul P 'Stingray' Komkoff Jr // http://stingr.net/key <- my pgp key This message represents the official view of the voices in my head From tmus at tmus.dk Tue Dec 20 14:19:56 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Tue, 20 Dec 2005 15:19:56 +0100 Subject: fedora logo shows promise Message-ID: I've had a big nag against the newly proposed fedora logo for a lot of reasons. IMHO the versions that's been on display till now have been plain ugly. Luckily the latest default wallpaper somewhat changes that appearance. There is probably still room for improvement, but Diana Fong has done a tremendous job in making the logo look a *lot* better. Just wanted to say thanks! /Thomas From tmus at tmus.dk Tue Dec 20 14:34:13 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Tue, 20 Dec 2005 15:34:13 +0100 Subject: fedora logo shows promise In-Reply-To: References: Message-ID: Thomas M Steenholdt wrote: > I've had a big nag against the newly proposed fedora logo for a lot of > reasons. IMHO the versions that's been on display till now have been > plain ugly. > > Luckily the latest default wallpaper somewhat changes that appearance. > There is probably still room for improvement, but Diana Fong has done a > tremendous job in making the logo look a *lot* better. > > Just wanted to say thanks! > > /Thomas > Now if we can somehow bring the fedora-logos package with all the icons and stuff up to speed and make the default theme match these colors - I, for on, will be very happy with the outcome of the fedora logo "wars". /Thomas From buildsys at redhat.com Tue Dec 20 08:19:50 2005 From: buildsys at redhat.com (Build System) Date: Tue, 20 Dec 2005 03:19:50 -0500 Subject: rawhide report: 20051220 changes Message-ID: <200512200819.jBK8JoHM013990@porkchop.devel.redhat.com> New package libvir Library providing an API to use the Xen virtualization Updated Packages: GFS-kernel-2.6.14.1-20051219.162641.FC5.2 ----------------------------------------- * Mon Dec 19 2005 Chris Feist - rebuilt ORBit2-2.13.2-2 --------------- * Mon Dec 19 2005 Matthias Clasen 2.13.2-2 - Fix multilib issues anaconda-10.90.22-1 ------------------- * Mon Dec 19 2005 Jeremy Katz - 10.90.22-1 - add more encoding modules to traceonly (clumens, #175853) - Fix text installs (pnasrat, #175773) - Fix for yum API changes (pnasrat) - Don't install the smp kernel even if NX is available - Adjust to be more dynamic about colors with syslinux-splash's - Use the selected language for default keyboard layout (clumens, #172266) - Better naming for psuedo-filesystems in /etc/fstab (dcantrel, #176149) - Clean up image handling for new graphics - Don't do the splashscreen stuff anymore. If the window is too slow to appear, we should fix that instead arts-8:1.5.0-1 -------------- * Mon Dec 19 2005 Than Ngo 1.5.0-1 - apply patch to fix #169631 automake-1.9.6-2 ---------------- * Mon Dec 19 2005 Karsten Hopp 1.9.6-2 - include NEWS file (#174674) - add %check (#174674) automake15-1.5-14 ----------------- * Mon Dec 19 2005 Karsten Hopp 1.5-14 - fix insthook test: tail needs parameters '-n +NUMLINES' instead of '+NUMLINES' now * Fri Dec 09 2005 Jesse Keating - rebuilt caching-nameserver-7.3-4.FC5 ---------------------------- * Sun Dec 18 2005 Jason Vas Dias 7.3-4 - update for version differences FC-3 -> 4 -> 5 check-0.9.3-4.fc5 ----------------- * Mon Dec 19 2005 Warren Togami 0.9.2-4 - import into FC5 for gstreamer-0.10 * Fri Dec 02 2005 Tom "spot" Callaway 0.9.2-3 - enabled -fPIC to resolve bz 174313 * Sat Sep 17 2005 Tom "spot" Callaway 0.9.2-2 - get rid of the so file (not needed) - only make devel package cman-kernel-2.6.14.1-20051219.162641.FC5.3 ------------------------------------------ * Mon Dec 19 2005 Chris Feist - rebuilt cpufreq-utils-1:0.4-1.1.21 -------------------------- * Mon Dec 19 2005 Dave Jones - New upstream 0.4 release. cups-1:1.1.23-27 ---------------- * Mon Dec 19 2005 Tim Waugh 1:1.1.23-27 - Link pdftops with -z relro. cvs-1.11.21-2 ------------- * Wed Dec 14 2005 Martin Stransky 1.11.21-2 - fix for cvs diff with two -r switches (#18161) - pam patch (#48937) - CVS_RSH is set to ssh (#58699) cyrus-sasl-2.1.21-9 ------------------- * Mon Dec 19 2005 Nalin Dahyabhai 2.1.21-9 - use --as-needed to avoid linking dbconverter-2 with SQL libraries, which it doesn't use because it manipulates files directly (#173321) desktop-backgrounds-2.0-31 -------------------------- * Mon Dec 19 2005 Ray Strode 2.0-31 - replace default fedora background with new one from Diana Fong device-mapper-multipath-0.4.5-9.1 --------------------------------- * Mon Dec 19 2005 Benjamin Marzinski - 0.4.5-9.1 - added patch for fedora changes * Fri Dec 16 2005 Benjamin Marzinski - 0.4.5-9.0 - Updated to latest upstream source (t)_4_5_post52) dlm-kernel-2.6.14.1-20051219.162641.FC5.2 ----------------------------------------- * Mon Dec 19 2005 Chris Feist - rebuilt docbook-style-dsssl-1.79-3 -------------------------- * Mon Dec 19 2005 Tim Waugh 1.79-3 - Rebuilt. doxygen-1:1.4.5-3 ----------------- * Mon Dec 19 2005 Than Ngo 1.4.5-3 - apply patch to fix build problem with gcc-4.1 * Fri Dec 09 2005 Jesse Keating - rebuilt eclipse-1:3.1.1-1jpp_12fc ------------------------- * Mon Dec 19 2005 Igor Foox 3.1.1-1jpp_12fc - New version of launcher path (rh#175454). * Mon Dec 19 2005 Andrew Overholt 3.1.1-1jpp_11fc - Update patch for offline javadoc linking. - Rebuild with new gjdoc (rh#161147). evolution-2.5.3-1 ----------------- * Mon Dec 19 2005 David Malcolm - 2.5.3-1 - 2.5.3 - Updated patch 106 (evolution-2.2.2-commit-enter-on-calendar.patch) so that it still applies cleanly * Thu Dec 15 2005 Christopher Aillon 2.5.2-2 - Require nspr and nss instead of mozilla-nspr and mozilla-nss - Update no-gnome-common patch to work with standalone nss package evolution-connector-2.5.3-1 --------------------------- * Mon Dec 19 2005 David Malcolm - 2.5.3-1 - 2.5.3 - regenerate patch 200 - add patch to use correct marshalling code (patch 300) - dropped glob of etspec files evolution-data-server-1.5.3-2 ----------------------------- * Mon Dec 19 2005 David Malcolm - 1.5.3-2 - Update specfile and patch 5 (evolution-data-server-1.3.5-nspr_fix.patch) to use nss rather than mozilla-nss throughout * Mon Dec 19 2005 David Malcolm - 1.5.3-1 - 1.5.3 fedora-logos-1.1.35-1 --------------------- * Mon Dec 19 2005 Jeremy Katz - 1.1.35-1 - new images from dfong gdb-6.3.0.0-1.94 ---------------- * Mon Dec 19 2005 Alexandre Oliva 6.3.0.0-1.94 - Fix type-punning warnings issued by GCC 4.1. * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj * Thu Dec 01 2005 Jeff Johnston 6.3.0.0-1.93 - Bump up release number. gjdoc-0.7.7-1 ------------- * Mon Dec 19 2005 Andrew Overholt 0.7.7-1 - 0.7.7. gnbd-kernel-2.6.14.0-20051108.134753.FC5.12.2 --------------------------------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt gnome-libs-1:1.4.1.2.90-48 -------------------------- * Mon Dec 19 2005 Bill Nottingham - 1.1.4.1.2.90-48 - #175669 is fixed, rebuild with normal flags gnome-screensaver-0.0.22-3 -------------------------- * Mon Dec 19 2005 Matthias Clasen - 0.0.22-3 - add floaters lock dialog gtkhtml3-3.9.3-1 ---------------- * Mon Dec 19 2005 David Malcolm - 3.9.3-1 - 3.9.3 imake-1.0.0-2 ------------- * Mon Dec 19 2005 Than Ngo 1.0.0-2 - add some macros to fix problem in building of manpages * Sat Dec 17 2005 Mike A. Harris 1.0.0-1 - Updated all packages to version 1.0.0 from X11R7 RC4 - Added new lndir, gccmakedep tarballs. - Changed manpage dirs from man1x to man1 to match upstream RC4 default. - Removed all previous 'misc' patch, as we now pass --with-config-dir to configure to specify the location of the Imake config files. - Renamed imake patch to xorg-cf-files-1.0.0-ProjectRoot.patch as it did not patch imake at all. This should probably be changed to be a custom Red Hat host.def file that is added as a source line instead of randomly patching various files. * Fri Dec 09 2005 Jesse Keating 0.99.2-5.1 - rebuilt kernel-2.6.14-1.1776_FC5 ------------------------ * Mon Dec 19 2005 Dave Jones - 2.6.15-rc6 - Various ub stability improvements from Pete Zaitcev. - Update ACPICA. libselinux-1.29.2-2 ------------------- * Mon Dec 19 2005 Dan Walsh 1.29.2-2 - Move libselinux.so to base package libusb-0.1.10a-3 ---------------- * Mon Dec 19 2005 Tim Waugh 0.1.10a-3 - Rebuild. * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj * Mon Nov 21 2005 Tim Waugh 0.1.10a-2 - Build does not require xorg-x11-devel. Fixes rebuild problem (no more xorg-x11-devel package). libwvstreams-4.2.1-1 -------------------- * Mon Dec 19 2005 Harald Hoyer 4.2.1-1 - version 4.2.1 * Fri Dec 09 2005 Jesse Keating - rebuilt mcelog-1:0.5-1.13 ----------------- * Mon Dec 19 2005 Dave Jones - Update to upstream 0.5 mesa-6.4.1-1 ------------ * Sat Dec 17 2005 Mike A. Harris 6.4.1-1 - Updated MesaLib tarball to version 6.4.1 from Mesa project for X11R7 RC4. - Added pkgconfig dependency. - Updated "BuildRequires: libdrm-devel >= 2.0-1" - Added Obsoletes lines to all the subpackages to have cleaner upgrades. - Added mesa-6.4.1-amd64-assyntax-fix.patch to work around a build problem on AMD64, which is fixed in the 6.4 branch of Mesa CVS. - Conditionalize libOSMesa inclusion, and default to not including it for now. * Fri Dec 09 2005 Jesse Keating 6.4-5.1 - rebuilt * Sun Nov 20 2005 Jeremy Katz 6.4-5 - fix directory used for loading dri modules (#173679) - install dri drivers as executable so they get stripped (#173292) mkinitrd-5.0.15-1 ----------------- * Mon Dec 19 2005 Peter Jones - 5.0.15-1 - Don't open init's console with close-on-exec * Sun Dec 18 2005 Peter Jones - 5.0.14-1 - Remove vestigial loopback support. - Remove email addresses from man pages (which still need some work) nmap-2:3.95-1 ------------- * Mon Dec 19 2005 Harald Hoyer - 2:3.95-1 - version 3.95 * Fri Dec 09 2005 Jesse Keating - rebuilt openjade-1.3.2-22 ----------------- * Mon Dec 19 2005 Tim Waugh 1.3.2-22 - Fix SOC files. - Quieten scriptlets. * Mon Dec 19 2005 Tim Waugh 1.3.2-21 - Fix location of catalog. openoffice.org-1:2.0.1.1-1.2 ---------------------------- * Thu Dec 15 2005 Caolan McNamara - 1:2.0.1.1-1 - gcc#25199# fixed, drop bitfield patch - gcc#25389# fixed, drop jurt.nullpointer.patch - gcc#25426# identified, crash with jaxpapi patch - addressbooks a) evo1 addressbook removed, as only evo2 required b) mozilla addressbook removed, utterly useless c) evo2 ldap addressbook added to give some sort of ldap access d) patch wizard UI to show available addressbook backends - add openoffice.org-2.0.1.oooXXXXX.config_office.nss.patch - upstream cocks up their numbering pam_krb5-2.2.3-1 ---------------- * Mon Dec 19 2005 Nalin Dahyabhai - 2.2.3-1 - fix a compile problem caused by a missing #include (Jesse Keating) pango-1.11.1-2 -------------- * Mon Dec 19 2005 Matthias Clasen - 1.11.1-2 - BuildRequire cairo-devel perl-DBI-1.50-1 --------------- * Mon Dec 19 2005 Jason Vas Dias - 1.50-1 - upgrade to 1.50 perl-HTML-Parser-3.48-1 ----------------------- * Mon Dec 19 2005 Jason Vas Dias - 3.48-1 - upgrade to 3.48 perl-Net-DNS-0.55-1 ------------------- * Mon Dec 19 2005 Jason Vas Dias - 0.55-1 - Upgrade to upstream version 0.55 perl-XML-SAX-0.13-1 ------------------- * Mon Dec 19 2005 Jason Vas Dias - upgrade to 0.13 perl-XML-Twig-3.22-1 -------------------- * Mon Dec 19 2005 Jason Vas Dias - 3.22-1 - Update to 3.22 perl-libwww-perl-5.805-1 ------------------------ * Sun Dec 18 2005 Jason Vas Dias - 5.805-1 - Upgrade to 5.805-1 policycoreutils-1.29.2-3 ------------------------ * Wed Dec 14 2005 Dan Walsh 1.29.2-3 - Remove commands from genhomedircon for installer python-pyblock-0.9-1 -------------------- * Mon Dec 19 2005 Peter Jones - 0.9-1 - fix some backwards isinstance() calls that cause RaidSet.get_valid() to fail readahead-1:1.1-1.19.1 ---------------------- * Mon Dec 19 2005 Karel Zak - sync versioned gcc, firefox, openoffice.org, evolution dirs with FC5 selinux-policy-2.1.6-11 ----------------------- * Mon Dec 19 2005 Dan Walsh 2.1.6-11 - Add man pages * Fri Dec 16 2005 Dan Walsh 2.1.6-10 - Add enableaudit.pp * Fri Dec 16 2005 Dan Walsh 2.1.6-9 - Fix mls policy shared-mime-info-0.16.cvs20051219-1 ----------------------------------- * Mon Dec 19 2005 Matthias Clasen - 0.16.cvs20051219-1 - Newer cvs snapshot squid-7:2.5.STABLE12-3 ---------------------- * Mon Dec 19 2005 Martin Stransky 7:2.5.STABLE12-3 - fd-config.patch clean-up - SMB_BadFetch patch from upstream system-config-bind-4.0.0-33_FC5 ------------------------------- * Mon Dec 19 2005 Jason Vas Dias - 4.0.0-33 - fix bug 175420: traceback when named.conf included a nonexistent file - fix bug 176142: ship updated Serbian translation * Fri Dec 09 2005 Jesse Keating - rebuilt system-config-netboot-0.1.34-1 ------------------------------ * Mon Dec 19 2005 Jason Vas Dias - 0.1.34-1 - fix bug 174942: make diskless clients free initrd memory - fix bug 174941: fix mkdiskless syslog.conf typo: '*' -> '*.*' - fix bug 176144: ship updated translations systemtap-0.5.2-2 ----------------- * Mon Dec 19 2005 Roland McGrath - 0.5.2-2 - Rebuilt for devel * Mon Dec 19 2005 Roland McGrath - 0.5.2-1 - Fixed build with gcc 4.1, various tapset changes. * Wed Dec 07 2005 Roland McGrath - 0.5.1-1 - elfutils update, build changes transfig-1:3.2.4-13 ------------------- * Mon Dec 19 2005 Than Ngo 3.2.4-13 - fix build problem with modular X * Fri Dec 09 2005 Jesse Keating - rebuilt wvdial-1.54.0-5.2 ----------------- * Mon Dec 19 2005 Harald Hoyer - rebuilt xdoclet-0:1.2.2-2jpp_3fc ------------------------ * Mon Dec 19 2005 Archit Shah - 0:1.2.2-2jpp_3fc - Remove use of external javadoc URLs from javadoc task. * Fri Dec 09 2005 Jesse Keating - 0:1.2.2-2jpp_2fc - rebuilt xorg-x11-utils-1.0.0-1 ---------------------- * Sat Dec 17 2005 Mike A. Harris 1.0.0-1 - Updated all tarballs to version 1.0.0 from X11R7 RC4. - Changed manpage dir from man1x to man1 to match upstream RC4 default. - Moved all app-defaults files from _libdir to _datadir xorg-x11-xbitmaps-1.0.0-1 ------------------------- * Sat Dec 17 2005 Mike A. Harris 1.0.0-1 - Updated to xbitmaps 1.0.0 from X11R7 RC4. xorg-x11-xkb-utils-1.0.0-1 -------------------------- * Sat Dec 17 2005 Mike A. Harris 1.0.0-1 - Updated all apps to version 1.0.0 from X11R7 RC4. - Changed manpage dir from man1x to man1 to match upstream default. xorg-x11-xkbdata-1.0.0-1 ------------------------ Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.2.i686 requires /lib/modules/2.6.14-1.1775_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.2.i686 requires kernel = 0:2.6.14-1.1775_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.2.i686 requires kernel-smp = 0:2.6.14-1.1775_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.2.i686 requires /lib/modules/2.6.14-1.1775_FC5smp cman-kernel - 2.6.14.1-20051219.162641.FC5.3.i686 requires /lib/modules/2.6.14-1.1775_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.3.i686 requires kernel = 0:2.6.14-1.1775_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.3.i686 requires kernel-smp = 0:2.6.14-1.1775_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.3.i686 requires /lib/modules/2.6.14-1.1775_FC5smp control-center - 1:2.13.3-1.i386 requires libedataserver-1.2.so.4 dlm-kernel - 2.6.14.1-20051219.162641.FC5.2.i686 requires /lib/modules/2.6.14-1.1775_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.2.i686 requires kernel = 0:2.6.14-1.1775_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.2.i686 requires kernel-smp = 0:2.6.14-1.1775_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.2.i686 requires /lib/modules/2.6.14-1.1775_FC5smp evolution-webcal - 2.4.1-1.1.i386 requires libedataserver-1.2.so.4 gaim - 1:1.5.0-9.fc5.1.i386 requires libedataserver-1.2.so.4 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.2.i686 requires /lib/modules/2.6.14-1.1775_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.2.i686 requires kernel = 0:2.6.14-1.1775_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.2.i686 requires kernel-smp = 0:2.6.14-1.1775_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.2.i686 requires /lib/modules/2.6.14-1.1775_FC5smp gnome-panel - 2.13.3-1.i386 requires libedataserver-1.2.so.4 gnome-python2-libgtop2 - 2.12.1-7.1.i386 requires libgtop-2.0.so.5 gnomemeeting - 1.2.3-1.i386 requires libedataserver-1.2.so.4 jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 nautilus-sendto - 0.4-5.1.i386 requires libedataserver-1.2.so.4 Broken deps for ia64 ---------------------------------------------------------- control-center - 1:2.13.3-1.ia64 requires libedataserver-1.2.so.4()(64bit) evolution-webcal - 2.4.1-1.1.ia64 requires libedataserver-1.2.so.4()(64bit) gaim - 1:1.5.0-9.fc5.1.ia64 requires libedataserver-1.2.so.4()(64bit) gnome-panel - 2.13.3-1.ia64 requires libedataserver-1.2.so.4()(64bit) gnome-python2-libgtop2 - 2.12.1-7.1.ia64 requires libgtop-2.0.so.5()(64bit) gnomemeeting - 1.2.3-1.ia64 requires libedataserver-1.2.so.4()(64bit) jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) nautilus-sendto - 0.4-5.1.ia64 requires libedataserver-1.2.so.4()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 control-center - 1:2.13.3-1.ppc requires libedataserver-1.2.so.4 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 evolution-webcal - 2.4.1-1.1.ppc requires libedataserver-1.2.so.4 gaim - 1:1.5.0-9.fc5.1.ppc requires libedataserver-1.2.so.4 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 gnome-panel - 2.13.3-1.ppc requires libedataserver-1.2.so.4 gnome-python2-libgtop2 - 2.12.1-7.1.ppc requires libgtop-2.0.so.5 gnomemeeting - 1.2.3-1.ppc requires libedataserver-1.2.so.4 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 nautilus-sendto - 0.4-5.1.ppc requires libedataserver-1.2.so.4 Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 control-center - 1:2.13.3-1.ppc64 requires libedataserver-1.2.so.4()(64bit) dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi evolution-webcal - 2.4.1-1.1.ppc64 requires libedataserver-1.2.so.4()(64bit) gaim - 1:1.5.0-9.fc5.1.ppc64 requires libedataserver-1.2.so.4()(64bit) gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 gnome-panel - 2.13.3-1.ppc64 requires libedataserver-1.2.so.4()(64bit) gnome-python2-libgtop2 - 2.12.1-7.1.ppc64 requires libgtop-2.0.so.5()(64bit) gnomemeeting - 1.2.3-1.ppc64 requires libedataserver-1.2.so.4()(64bit) jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) nautilus-sendto - 0.4-5.1.ppc64 requires libedataserver-1.2.so.4()(64bit) Broken deps for s390 ---------------------------------------------------------- control-center - 1:2.13.3-1.s390 requires libedataserver-1.2.so.4 evolution-webcal - 2.4.1-1.1.s390 requires libedataserver-1.2.so.4 gaim - 1:1.5.0-9.fc5.1.s390 requires libedataserver-1.2.so.4 gnome-panel - 2.13.3-1.s390 requires libedataserver-1.2.so.4 gnome-python2-libgtop2 - 2.12.1-7.1.s390 requires libgtop-2.0.so.5 gnomemeeting - 1.2.3-1.s390 requires libedataserver-1.2.so.4 jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 nautilus-sendto - 0.4-5.1.s390 requires libedataserver-1.2.so.4 systemtap - 0.5.2-2.s390 requires kernel >= 0:2.6.9-11 systemtap - 0.5.2-2.s390 requires kernel-devel Broken deps for s390x ---------------------------------------------------------- control-center - 1:2.13.3-1.s390x requires libedataserver-1.2.so.4()(64bit) evolution-webcal - 2.4.1-1.1.s390x requires libedataserver-1.2.so.4()(64bit) gaim - 1:1.5.0-9.fc5.1.s390x requires libedataserver-1.2.so.4()(64bit) gnome-panel - 2.13.3-1.s390x requires libedataserver-1.2.so.4()(64bit) gnome-panel - 2.13.3-1.s390 requires libedataserver-1.2.so.4 gnome-python2-libgtop2 - 2.12.1-7.1.s390x requires libgtop-2.0.so.5()(64bit) gnomemeeting - 1.2.3-1.s390x requires libedataserver-1.2.so.4()(64bit) jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) libgnome-java - 2.12.0-2.s390x requires libgcj.so.6()(64bit) libgnome-java - 2.12.0-2.s390x requires libcairojava-1.0.so()(64bit) libgtk-java - 2.8.0-7.s390x requires libgcj.so.6()(64bit) libvte-java - 0.11.11-6.3.s390x requires libcairojava-1.0.so()(64bit) nautilus-sendto - 0.4-5.1.s390x requires libedataserver-1.2.so.4()(64bit) systemtap - 0.5.2-2.s390x requires kernel >= 0:2.6.9-11 systemtap - 0.5.2-2.s390x requires kernel-devel Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.2.x86_64 requires /lib/modules/2.6.14-1.1775_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.2.x86_64 requires kernel = 0:2.6.14-1.1775_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.3.x86_64 requires /lib/modules/2.6.14-1.1775_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.3.x86_64 requires kernel = 0:2.6.14-1.1775_FC5 control-center - 1:2.13.3-1.x86_64 requires libedataserver-1.2.so.4()(64bit) dlm-kernel - 2.6.14.1-20051219.162641.FC5.2.x86_64 requires /lib/modules/2.6.14-1.1775_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.2.x86_64 requires kernel = 0:2.6.14-1.1775_FC5 evolution-webcal - 2.4.1-1.1.x86_64 requires libedataserver-1.2.so.4()(64bit) gaim - 1:1.5.0-9.fc5.1.x86_64 requires libedataserver-1.2.so.4()(64bit) gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.2.x86_64 requires /lib/modules/2.6.14-1.1775_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.2.x86_64 requires kernel = 0:2.6.14-1.1775_FC5 gnome-panel - 2.13.3-1.i386 requires libedataserver-1.2.so.4 gnome-panel - 2.13.3-1.x86_64 requires libedataserver-1.2.so.4()(64bit) gnome-python2-libgtop2 - 2.12.1-7.1.x86_64 requires libgtop-2.0.so.5()(64bit) gnomemeeting - 1.2.3-1.x86_64 requires libedataserver-1.2.so.4()(64bit) jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) nautilus-sendto - 0.4-5.1.x86_64 requires libedataserver-1.2.so.4()(64bit) -- fedora-test-list mailing list fedora-test-list at redhat.com To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-test-list From ottohaliburton at comcast.net Tue Dec 20 14:52:41 2005 From: ottohaliburton at comcast.net (Otto Haliburton) Date: Tue, 20 Dec 2005 08:52:41 -0600 Subject: yum downloads need revamping Message-ID: <1135090361.3631.3.camel@c515816-a> When doing a yum update, it selects all the package available without giving a choice as to what packages to download i.e. downloading openoffice downloads all language flavors which means that i get everything and I only want english, and this happens to everyone. It is a terrible waste of bandwidth, the solution of course is to allow selection of only the flavor you want. This is a suggestion for discussion and development. -- Otto Haliburton From m.f.h at web.de Tue Dec 20 15:04:29 2005 From: m.f.h at web.de (Marcus Hartig) Date: Tue, 20 Dec 2005 16:04:29 +0100 Subject: rawhide report: 20051220 changes In-Reply-To: <17971.194.94.224.254.1135083306.squirrel@jose.freesurf.fr> References: <43A7E451.5030501@web.de> <17971.194.94.224.254.1135083306.squirrel@jose.freesurf.fr> Message-ID: <43A81D7D.9000805@web.de> Joachim Frieben wrote: > How perception differs ...! I do find the new "grub" image and > the default background very unpleasant. Strange colour hues and > way too bright, when the previous Fedora default background was > much too dark. One can barely read the icon subtitles. ?hh, I mean the desktop picture. The grub logo is too bright, yes. It's not so nice with these strange colors. Marcus From nicolas.mailhot at laposte.net Tue Dec 20 15:01:43 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Tue, 20 Dec 2005 16:01:43 +0100 (CET) Subject: Too much time wasted installing fedora on raid1 In-Reply-To: <1135084820.4066.31.camel@pmac.infradead.org> References: <20051219201653.GU1556@stingr.net> <1135026753.2947.23.camel@laptopd505.fenrus.org> <20051220085657.GW1556@stingr.net> <1135071978.2952.8.camel@laptopd505.fenrus.org> <20051220101303.GB23000@ryoko.camperquake.de> <1135073956.2952.10.camel@laptopd505.fenrus.org> <1135082117.3154.5.camel@localhost.localdomain> <36717.192.54.193.25.1135083965.squirrel@rousalka.dyndns.org> <1135084820.4066.31.camel@pmac.infradead.org> Message-ID: <57077.192.54.193.25.1135090903.squirrel@rousalka.dyndns.org> On Mar 20 d?cembre 2005 14:20, David Woodhouse wrote: > On Tue, 2005-12-20 at 14:06 +0100, Nicolas Mailhot wrote: >> I don't know how anaconda handles it but the default raid IO limits are >> very conservative (optimized for background work on a live system) >> >> On a system being created it's probably a better idea to tell the raid >> system to pump as much blocks as possible, since this is a blocking op >> in >> this context and we don't care about anything else. > > I think you miss the point. On a file system which is being created, the > bandwidth limits _ought_ to be fairly much irrelevant. No they're not. If I remember well during an update anaconda can transform some existing logical volumes to redundant volumes, so you can have a fairly big mass of data to transfer. And the bandwidth limits are *very* conservative. You won't win 5% or even half the time, sometimes it's a 10x (+) diff?rence. -- Nicolas Mailhot From jspaleta at gmail.com Tue Dec 20 15:06:04 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 20 Dec 2005 10:06:04 -0500 Subject: yum downloads need revamping In-Reply-To: <1135090361.3631.3.camel@c515816-a> References: <1135090361.3631.3.camel@c515816-a> Message-ID: <604aa7910512200706u1fcc7fdasfa8465172c235624@mail.gmail.com> On 12/20/05, Otto Haliburton wrote: > When doing a yum update, it selects all the package available without > giving a choice as to what packages to download i.e. downloading > openoffice downloads all language flavors which means that i get > everything and I only want english, and this happens to everyone. It happens to everyone? Doesn't happen to me.... because when i did my install.. i only selected english. If you don't want the addional language packages to be updated.. don't install the additional language packages to begin with.. or remove the ones you don't want on your system. And if you want specific packages excluded from update commands learn to use the --exclude cmdline option or the exclude configuration switch in the config files yum is using. -jef From tmus at tmus.dk Tue Dec 20 14:56:10 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Tue, 20 Dec 2005 15:56:10 +0100 Subject: yum downloads need revamping In-Reply-To: <1135090361.3631.3.camel@c515816-a> References: <1135090361.3631.3.camel@c515816-a> Message-ID: Otto Haliburton wrote: > When doing a yum update, it selects all the package available without > giving a choice as to what packages to download i.e. downloading > openoffice downloads all language flavors which means that i get > everything and I only want english, and this happens to everyone. It is > a terrible waste of bandwidth, the solution of course is to allow > selection of only the flavor you want. This is a suggestion for > discussion and development. This is because you have all the language components install to begin with. The old languages needs to be updated as well because the old ones are dependent on the old version of openoffice (to continue your example). Just don't install all the stuff you don't want in the first place and you should be good. /Thomas From ottohaliburton at comcast.net Tue Dec 20 15:30:44 2005 From: ottohaliburton at comcast.net (Otto Haliburton) Date: Tue, 20 Dec 2005 09:30:44 -0600 Subject: yum downloads need revamping In-Reply-To: <604aa7910512200706u1fcc7fdasfa8465172c235624@mail.gmail.com> References: <1135090361.3631.3.camel@c515816-a> <604aa7910512200706u1fcc7fdasfa8465172c235624@mail.gmail.com> Message-ID: <1135092644.3631.12.camel@c515816-a> On Tue, 2005-12-20 at 10:06 -0500, Jeff Spaleta wrote: > On 12/20/05, Otto Haliburton wrote: > > When doing a yum update, it selects all the package available without > > giving a choice as to what packages to download i.e. downloading > > openoffice downloads all language flavors which means that i get > > everything and I only want english, and this happens to everyone. > > It happens to everyone? Doesn't happen to me.... because when i did > my install.. i only selected english. If you don't want the addional > language packages to be updated.. don't install the additional > language packages to begin with.. or remove the ones you don't want on > your system. > > And if you want specific packages excluded from update commands learn > to use the --exclude cmdline option or the exclude configuration > switch in the config files yum is using. > > > -jef > well, i can agree with you if fedora was a production system, as far as I know it is a development system and the object is to select a complete download, and I guess you must pay the penalty for that, the problem also occurs with the kde update too. I think that there should be a solution that allows you to select. The further problem with the response is in using the exclude config switch you might have a slight problem in excluding everything except the english updates etc. A more positive aspect for the solution is that yum detects the fact that multilanguages are available and prompts for inclusion of all or the inclusion of a selected language giving you the best of both worlds. -- Otto Haliburton From seanlkml at sympatico.ca Tue Dec 20 15:35:17 2005 From: seanlkml at sympatico.ca (Sean) Date: Tue, 20 Dec 2005 10:35:17 -0500 (EST) Subject: bittorrent in core? what frontend? In-Reply-To: <43A7F94F.902@city-fan.org> References: <1134662961.28842.128.camel@greebo> <20051215202126.GA4210@devserv.devel.redhat.com> <1134721846.28842.166.camel@greebo> <20051217070856.GD24500@devserv.devel.redhat.com> <1134979247.28842.210.camel@greebo> <43A6E55D.9070303@city-fan.org> <43A7F94F.902@city-fan.org> Message-ID: On Tue, December 20, 2005 7:30 am, Paul Howarth said: Hi Paul, > Which version of bittorrent are you using? Looking at the code, it looks > to me that the update-checking code is only enabled for Windows and OSX > unless the DEBUG flag is set. I haven't looked at the code but it is definitely coming up with an update notification. I'm using bittorrent-4.2.1-1.fc5 and it reports that 4.2.2 is available. > I now share the view that the new version check should be disabled. > However, I've so far been unable to provoke the client into telling me > about a new version, even though I've got an old one installed, so it's > difficult to test any patch I make (which will certainly need testing > since I'm not a python programmer). If you remove or rename your ~/.bittorrent directory, the notification should pop up the next time you start the client. Sean From ottohaliburton at comcast.net Tue Dec 20 15:36:43 2005 From: ottohaliburton at comcast.net (Otto Haliburton) Date: Tue, 20 Dec 2005 09:36:43 -0600 Subject: yum downloads need revamping In-Reply-To: <1135092644.3631.12.camel@c515816-a> References: <1135090361.3631.3.camel@c515816-a> <604aa7910512200706u1fcc7fdasfa8465172c235624@mail.gmail.com> <1135092644.3631.12.camel@c515816-a> Message-ID: <1135093004.3631.15.camel@c515816-a> On Tue, 2005-12-20 at 09:30 -0600, Otto Haliburton wrote: > On Tue, 2005-12-20 at 10:06 -0500, Jeff Spaleta wrote: > > On 12/20/05, Otto Haliburton wrote: > > > When doing a yum update, it selects all the package available without > > > giving a choice as to what packages to download i.e. downloading > > > openoffice downloads all language flavors which means that i get > > > everything and I only want english, and this happens to everyone. > > > > It happens to everyone? Doesn't happen to me.... because when i did > > my install.. i only selected english. If you don't want the addional > > language packages to be updated.. don't install the additional > > language packages to begin with.. or remove the ones you don't want on > > your system. > > > > And if you want specific packages excluded from update commands learn > > to use the --exclude cmdline option or the exclude configuration > > switch in the config files yum is using. > > > > > > -jef > > > well, i can agree with you if fedora was a production system, as far as > I know it is a development system and the object is to select a complete > download, and I guess you must pay the penalty for that, the problem > also occurs with the kde update too. I think that there should be a > solution that allows you to select. The further problem with the > response is in using the exclude config switch you might have a slight > problem in excluding everything except the english updates etc. A more > positive aspect for the solution is that yum detects the fact that > multilanguages are available and prompts for inclusion of all or the > inclusion of a selected language giving you the best of both worlds. > -- > Otto Haliburton > further, I have recently updated openoffice using yum and this did not happen so something has changed either at the repository or with yum. -- Otto Haliburton From mike.cohler at gmail.com Tue Dec 20 15:47:51 2005 From: mike.cohler at gmail.com (Mike Cohler) Date: Tue, 20 Dec 2005 15:47:51 +0000 Subject: Fedora Core 5 Test 2 slipping until January 16 Message-ID: <3dd77c60512200747i1defe450t7ed101d4a20043fb@mail.gmail.com> Thanks for sweetening the news with the fun lyrics! Either way for what its worth, I would rather a little extra time be taken to get these releases working well rather than rushing to push out something on time which had serious bugs remaining to cause significant problems - In the end the system will be cutting edge but also a very fine operating system. Best wishes Mike Jesse Keating wrote: Broken deps still there Making testing fun We really thing we need to test for another month! Oh, software sucks, Software sucks, Software really sucks! Oh what fun it is to slip our release for a month! Oh What Fun It Is To Slip Our Release For A Monnnnnnnnnnnnnnnnth!!! Ok, it won't be a full month, but due to the recent upgrade of gcc and the subsequent full rebuild of everything that does (and doesn't, whoops!) get built with gcc, including java stuff with gcj, and the need to further test package selection windows in Anaconda, system-config-packages for upgrades, and the development tree in general once we settle down the rebuilds, we have decided to delay test2. Here is a new schedule that we will be working toward: * Test2 freeze date to 9 January * Test2 release, 16 January * Test3 freeze, 6 February * Test3 release, 13 February * Final absolute freeze, 6 March * Release, 15 March We are going to try very hard to have a stable(ish) tree suitable for testing over the holidays, so that Test2 will be better for the slip and keep us in line with getting Test3 and eventually the final release out in the best shape possible. Thank you all for your hard work in helping us develop the best distribution we can! -- Jesse Keating Release Engineer: Fedora -- mike cohler -------------- next part -------------- An HTML attachment was scrubbed... URL: From jspaleta at gmail.com Tue Dec 20 15:48:13 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 20 Dec 2005 10:48:13 -0500 Subject: yum downloads need revamping In-Reply-To: <1135092644.3631.12.camel@c515816-a> References: <1135090361.3631.3.camel@c515816-a> <604aa7910512200706u1fcc7fdasfa8465172c235624@mail.gmail.com> <1135092644.3631.12.camel@c515816-a> Message-ID: <604aa7910512200748w6a00b7f6n4fc7a1c20363a93e@mail.gmail.com> On 12/20/05, Otto Haliburton wrote: > well, i can agree with you if fedora was a production system, as far as > I know it is a development system and the object is to select a complete > download, Pretty sure noone sane thinks an "everything" install is a good idea. But you are free to continue to attempt them. >and I guess you must pay the penalty for that, the problem > also occurs with the kde update too. I think that there should be a > solution that allows you to select. As much as I hate agreeing with Steenholdt.. and let me assure you i hate having to do it it... i have to agree with him on this, because of the way the language packages for openoffice are packaged you can't avoid updating the langpacks at all. I think you have a poor understanding of how package dependancies work. So let me take a moment to step through what is going on here. In the case of the openoffice language packages the dependancy is versioned so that language packages are tied to a specific version of openoffice. You can not selectively choose which language packages to update without breaking dependancies. Yum is not going to be re-designed to let you break dependancies to avoid updating language packages...forget you ever had the thought. Example.. on fc4 right now: repoquery --requires openoffice.org-langpack-he_IL openoffice.org-core = 1:2.0.1-143.2.1 <------ VERSIONED DEPENDANCY same thing on rawhide too: repoquery --repoid=development --requires openoffice.org-langpack-he_IL openoffice.org-core = 1:2.0.1.1-1.2 Back on that fc4 system, if I have the package openoffice.org-langpack-he_IL installed and I want to update openoffice.org-core to version 2.0.1-143.2.1 the dependancy situation demands that I also update the language package. Yum isn't going to allow you to delibrately break explicit dependancy chains... no way... no how. -jef From mike.cohler at gmail.com Tue Dec 20 16:04:27 2005 From: mike.cohler at gmail.com (Mike Cohler) Date: Tue, 20 Dec 2005 16:04:27 +0000 Subject: yum downloads need revamping Message-ID: <3dd77c60512200804t4f25179ciac9ce2eb1f6b4e5c@mail.gmail.com> Jeff Spaleta wrote: As much as I hate agreeing with Steenholdt.. and let me assure you i hate having to do it it... i have to agree with him on this, because of the way the language packages for openoffice are packaged you can't avoid updating the langpacks at all. The way I have been using openoffice is to do a "yum remove openoffice.org-langpack*" and since I am only in need of English this saves a huge set of downloads whenever openoffice is updated. Hence this one command helps a lot for future updates. Of course if you needed a specific langauge support then you could follow the above with yum install openoffice.org-langpack-he_IL or whatever you need - this is still a great saving in dowload time/space and update time/space compared to leaving everything in your system even if you don;t need it. Hence even if everything else is downloaded at install you can make the above change and still be efficient for updates. Jeff has already hinted at this in a previous posting on this topic. A similar trick can be played concerning kde-i18n-* again in my case I keep kde-i18n-British but remove the other language support rpms via yum remove. I would imagine that most people would need only 1 or possibly a few language support files on any single machine? Mike -- mike cohler -------------- next part -------------- An HTML attachment was scrubbed... URL: From ottohaliburton at comcast.net Tue Dec 20 16:04:09 2005 From: ottohaliburton at comcast.net (Otto Haliburton) Date: Tue, 20 Dec 2005 10:04:09 -0600 Subject: yum downloads need revamping In-Reply-To: <604aa7910512200748w6a00b7f6n4fc7a1c20363a93e@mail.gmail.com> References: <1135090361.3631.3.camel@c515816-a> <604aa7910512200706u1fcc7fdasfa8465172c235624@mail.gmail.com> <1135092644.3631.12.camel@c515816-a> <604aa7910512200748w6a00b7f6n4fc7a1c20363a93e@mail.gmail.com> Message-ID: <1135094650.3631.23.camel@c515816-a> On Tue, 2005-12-20 at 10:48 -0500, Jeff Spaleta wrote: > On 12/20/05, Otto Haliburton wrote: > > well, i can agree with you if fedora was a production system, as far as > > I know it is a development system and the object is to select a complete > > download, > > Pretty sure noone sane thinks an "everything" install is a good idea. > But you are free to continue to attempt them. > > >and I guess you must pay the penalty for that, the problem > > also occurs with the kde update too. I think that there should be a > > solution that allows you to select. > > As much as I hate agreeing with Steenholdt.. and let me assure you i > hate having to do it it... i have to agree with him on this, because > of the way the language packages for openoffice are packaged you can't > avoid updating the langpacks at all. > > I think you have a poor understanding of how package dependancies > work. So let me take a moment to step through what is going on here. > In the case of the openoffice language packages the dependancy is > versioned so that language packages are tied to a specific version of > openoffice. You can not selectively choose which language packages to > update without breaking dependancies. Yum is not going to be > re-designed to let you break dependancies to avoid updating language > packages...forget you ever had the thought. > > Example.. on fc4 right now: > repoquery --requires openoffice.org-langpack-he_IL > openoffice.org-core = 1:2.0.1-143.2.1 <------ VERSIONED DEPENDANCY > same thing on rawhide too: > repoquery --repoid=development --requires openoffice.org-langpack-he_IL > openoffice.org-core = 1:2.0.1.1-1.2 > > Back on that fc4 system, if I have the package > openoffice.org-langpack-he_IL installed and I want to update > openoffice.org-core to version 2.0.1-143.2.1 the dependancy situation > demands that I also update the language package. Yum isn't going to > allow you to delibrately break explicit dependancy chains... no way... > no how. > > -jef > let me go even further cause basically i agree with you and when i started this discussion I realized that note i put for discussion and development. The problem is I went in and checked my package management stuff and guess what I had gone in and disabled language support, when i reenabled it I found that alot of the languages were selected, but I disabled it again somehow someway this is getting over ridden. About a month or so ago openoffice was updated and I didn't have this particular update of all the languages, but it got updated again and now I have all of the languages so something has changed. Anyway, that doesn't change the fact that there should be solution that will allow the best of all worlds, as to the dependacies, i should be able to update the dependancies for all language without updating the languages themselves, get my drift. -- Otto Haliburton From rdieter at math.unl.edu Tue Dec 20 16:07:12 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Tue, 20 Dec 2005 10:07:12 -0600 Subject: yum downloads need revamping In-Reply-To: <1135092644.3631.12.camel@c515816-a> References: <1135090361.3631.3.camel@c515816-a> <604aa7910512200706u1fcc7fdasfa8465172c235624@mail.gmail.com> <1135092644.3631.12.camel@c515816-a> Message-ID: <43A82C30.3070408@math.unl.edu> Otto Haliburton wrote: > I think that there should be a > solution that allows you to select. use yumex. -- Rex From seandarcy2 at gmail.com Tue Dec 20 16:12:29 2005 From: seandarcy2 at gmail.com (sean) Date: Tue, 20 Dec 2005 11:12:29 -0500 Subject: rawhide report: 20051220 changes In-Reply-To: <200512200819.jBK8JoHM013990@porkchop.devel.redhat.com> References: <200512200819.jBK8JoHM013990@porkchop.devel.redhat.com> Message-ID: Build System wrote: ............ > > selinux-policy-2.1.6-11 > ----------------------- > * Mon Dec 19 2005 Dan Walsh 2.1.6-11 > - Add man pages > > * Fri Dec 16 2005 Dan Walsh 2.1.6-10 > - Add enableaudit.pp > > * Fri Dec 16 2005 Dan Walsh 2.1.6-9 > - Fix mls policy > Updating : selinux-policy-targeted ##################### [ 52/153] Traceback (most recent call last): File "/usr/sbin/genhomedircon", line 350, in ? selconf.write() File "/usr/sbin/genhomedircon", line 314, in write fd.write(self.genoutput()) File "/usr/sbin/genhomedircon", line 305, in genoutput ret += self.genHomeDirContext() File "/usr/sbin/genhomedircon", line 254, in genHomeDirContext users = self.getUsers() File "/usr/sbin/genhomedircon", line 221, in getUsers role=self.getOldRole(user[1]) File "/usr/sbin/genhomedircon", line 167, in getOldRole rc=findval(self.selinuxdir+self.type+"/users/system.users", 'grep "^user %s" %s' % role, "=") TypeError: not enough arguments for format string libsemanage.semanage_install_sandbox: genhomedircon returned error code 1. libsemanage.parse_module_headers: Data did not represent a module. Failed! sean From pjones at redhat.com Tue Dec 20 16:57:02 2005 From: pjones at redhat.com (Peter Jones) Date: Tue, 20 Dec 2005 11:57:02 -0500 Subject: Too much time wasted installing fedora on raid1 In-Reply-To: <20051220101303.GB23000@ryoko.camperquake.de> References: <20051219201653.GU1556@stingr.net> <1135026753.2947.23.camel@laptopd505.fenrus.org> <20051220085657.GW1556@stingr.net> <1135071978.2952.8.camel@laptopd505.fenrus.org> <20051220101303.GB23000@ryoko.camperquake.de> Message-ID: <1135097822.3240.1.camel@localhost.localdomain> On Tue, 2005-12-20 at 11:13 +0100, Ralf Ertzinger wrote: > On Tue, Dec 20, 2005 at 10:46:18AM +0100, Arjan van de Ven wrote: > > > well... if the root is brand spanking new.. why would it need a sync? > > Because it _is_ brand spanking new (and thus unclean from a RAID point > of view)? Why does that matter? The parts of it we've written data out to are supposed to be in sync already. The resync should only be making the parts that aren't in use yet identical. -- Peter From pjones at redhat.com Tue Dec 20 17:01:17 2005 From: pjones at redhat.com (Peter Jones) Date: Tue, 20 Dec 2005 12:01:17 -0500 Subject: kernel-2.6.14-1.1653_FC4.netdev.6? In-Reply-To: <20051219224322.GA5815@rathann.pekin.waw.pl> References: <43A05044.7060803@cygnusx-1.org> <20051215005152.GF26108@rathann.pekin.waw.pl> <20051215010803.GE9801@redhat.com> <20051215162712.GC16712@redhat.com> <20051215215952.GC4336@rathann.pekin.waw.pl> <20051216131221.GA9708@redhat.com> <20051216225617.GC4376@rathann.pekin.waw.pl> <20051219224322.GA5815@rathann.pekin.waw.pl> Message-ID: <1135098078.3240.3.camel@localhost.localdomain> On Mon, 2005-12-19 at 23:43 +0100, Dominik 'Rathann' Mierzejewski wrote: > Additionally, I can't turn on debugging. modprobe ipw2200 debug=0xffff > output is no more verbose than without the debug option. With which kernel? I turned CONFIG_IPW_DEBUG back on several days ago... -- Peter From paul at city-fan.org Tue Dec 20 17:01:34 2005 From: paul at city-fan.org (Paul Howarth) Date: Tue, 20 Dec 2005 17:01:34 +0000 Subject: bittorrent in core? what frontend? In-Reply-To: References: <1134662961.28842.128.camel@greebo> <20051215202126.GA4210@devserv.devel.redhat.com> <1134721846.28842.166.camel@greebo> <20051217070856.GD24500@devserv.devel.redhat.com> <1134979247.28842.210.camel@greebo> <43A6E55D.9070303@city-fan.org> <43A7F94F.902@city-fan.org> Message-ID: <43A838EE.50101@city-fan.org> Sean wrote: > On Tue, December 20, 2005 7:30 am, Paul Howarth said: > > Hi Paul, > > >>Which version of bittorrent are you using? Looking at the code, it looks >>to me that the update-checking code is only enabled for Windows and OSX >>unless the DEBUG flag is set. > > > I haven't looked at the code but it is definitely coming up with an update > notification. I'm using bittorrent-4.2.1-1.fc5 and it reports that 4.2.2 > is available. > > >>I now share the view that the new version check should be disabled. >>However, I've so far been unable to provoke the client into telling me >>about a new version, even though I've got an old one installed, so it's >>difficult to test any patch I make (which will certainly need testing >>since I'm not a python programmer). > > > If you remove or rename your ~/.bittorrent directory, the notification > should pop up the next time you start the client. Indeed it does. I've done a quick patch, which seems to fix it for me at least. We'll see when 4.2.3 comes out ;-) Paul. From m.f.h at web.de Tue Dec 20 17:05:52 2005 From: m.f.h at web.de (Marcus Hartig) Date: Tue, 20 Dec 2005 18:05:52 +0100 Subject: gnome / xorg / nautilus / cairo / freetype desktop rendering slow In-Reply-To: <1135069920.3149.4.camel@localhost.localdomain> References: <43A7C889.8010904@web.de> <1135069920.3149.4.camel@localhost.localdomain> Message-ID: <43A839F0.7070608@web.de> Rodd Clarkson wrote: > I'm also unable to get better than 1600x1200 resolution on my 1920x1200 > screen. Have you tried to use a modeline: "gtf 1920 1200 60" # 1920x1200 @ 60.00 Hz (GTF) hsync: 74.52 kHz; pclk: 193.16 MHz Modeline "1920x1200_60.00" 193.16 1920 2048 2256 2592 1200 1201 1204 1242 -HSync +Vsync But then use "1920x1200_60.00" as resolution from this example. Line break is here also ath end! My xorg nv driver runs here also with the native 1440x900 only with a modeline in xorg.conf. :-( Marcus From vonbrand at inf.utfsm.cl Tue Dec 20 17:37:56 2005 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Tue, 20 Dec 2005 14:37:56 -0300 Subject: scim-libs not signed error when using yum?? In-Reply-To: Your message of "Tue, 20 Dec 2005 15:32:03 +0900." <43A7A563.2090101@redhat.com> Message-ID: <200512201737.jBKHbu4u014724@laptop11.inf.utfsm.cl> Jens Petersen wrote: > Gianluca Cecchi wrote: > > Package scim-libs-1.4.2-9.i386.rpm is not signed > Packages in FC Devel are not usually signed (except for packages included > from test releases). Could The Powers That Be consider signing the packages? Even with a rawhide-only key? That way I'd sleep a little better, knowing I've got no malicious gunk installed on my machine. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From jkeating at j2solutions.net Tue Dec 20 17:45:17 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 20 Dec 2005 09:45:17 -0800 Subject: scim-libs not signed error when using yum?? In-Reply-To: <200512201737.jBKHbu4u014724@laptop11.inf.utfsm.cl> References: <200512201737.jBKHbu4u014724@laptop11.inf.utfsm.cl> Message-ID: <200512200945.17534.jkeating@j2solutions.net> On Tuesday 20 December 2005 09:37, Horst von Brand wrote: > Could The Powers That Be consider signing the packages? Even with a > rawhide-only key? That way I'd sleep a little better, knowing I've got no > malicious gunk installed on my machine. It is test software, we aren't completely sure it isn't malicious gunk from upstream.... -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) From alan at clueserver.org Tue Dec 20 17:51:34 2005 From: alan at clueserver.org (alan) Date: Tue, 20 Dec 2005 09:51:34 -0800 (PST) Subject: Scribus in rawhide Message-ID: Could someone rebuild Scribus in Rawhide? It is dependant on a non-existant version of openssl. Error: Missing Dependency: libssl.so.5()(64bit) is needed by package scribus Error: Missing Dependency: libcrypto.so.5()(64bit) is needed by package scribus It has been like this for at least a week. Thanks! -- "George W. Bush -- Bringing back the Sixties one Nixon at a time." From jkeating at j2solutions.net Tue Dec 20 18:02:19 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 20 Dec 2005 10:02:19 -0800 Subject: Scribus in rawhide In-Reply-To: References: Message-ID: <1135101739.4131.3.camel@yoda.loki.me> On Tue, 2005-12-20 at 09:51 -0800, alan wrote: > Could someone rebuild Scribus in Rawhide? It is dependant on a > non-existant version of openssl. That would be an extras package. Best requested through the bugzilla for Extras. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 dax at gurulabs.com Tue Dec 20 18:11:20 2005 From: dax at gurulabs.com (Dax Kelson) Date: Tue, 20 Dec 2005 11:11:20 -0700 Subject: Everything installs (was: yum downloads need revamping) In-Reply-To: <604aa7910512200748w6a00b7f6n4fc7a1c20363a93e@mail.gmail.com> References: <1135090361.3631.3.camel@c515816-a> <604aa7910512200706u1fcc7fdasfa8465172c235624@mail.gmail.com> <1135092644.3631.12.camel@c515816-a> <604aa7910512200748w6a00b7f6n4fc7a1c20363a93e@mail.gmail.com> Message-ID: <1135102281.3445.17.camel@mentorng.gurulabs.com> On Tue, 2005-12-20 at 10:48 -0500, Jeff Spaleta wrote: > On 12/20/05, Otto Haliburton wrote: > > well, i can agree with you if fedora was a production system, as far as > > I know it is a development system and the object is to select a complete > > download, > > Pretty sure noone sane thinks an "everything" install is a good idea. > But you are free to continue to attempt them. For a "production" box (server) that is performing some defined task(s), I agree that "everything" is a bad idea. For a "power user"/developer box, I don't see any problem with an "everything" install. Hard disk space is cheap and you can find some cool apps you may not have found otherwise. Additionally, I can recall some situations where an application dynamically gets extra functionality and features if other *addon* or *plugin* packages get installed. For example, unless you have "kdeaddons" RPM installed the Konqueror browser doesn't have the ability to save a web page offline in a tarball. The menu item doesn't show up at all, what a mystery for someone not familiar with low level KDE interactions. When I discovered this a couple years ago the only way to get the "kdeaddons" RPMs installed during installation was via an "everything" install. Possibly this has changed now. Personally, I prefer an "Mostly english-only everything install" on my personal boxes. I do an "everything" install, and first thing after the install finishes I run: # trim some fat (1.1GB worth) rpm -e `rpm -qa | grep ^openoffice.org-langpack` # 600MB rpm -e `rpm -qa | grep ^kde-i18n` # 400MB rpm -e `rpm -qa | grep -E ^man-pages-[[:alpha:]]` # 100MB This may be helpful to the original poster. Dax Kelson Guru Labs From wcooley at nakedape.cc Tue Dec 20 18:12:30 2005 From: wcooley at nakedape.cc (Wil Cooley) Date: Tue, 20 Dec 2005 10:12:30 -0800 Subject: "yum --partial" feature as a bash line In-Reply-To: <1134683461.26513.6.camel@cutter> References: <439C0C8A.9090002@interia.pl> <1134517049.28114.65.camel@willow.odshp.com> <1134683461.26513.6.camel@cutter> Message-ID: <1135102350.24626.9.camel@willow.odshp.com> On Thu, 2005-12-15 at 16:51 -0500, seth vidal wrote: > > The problem with any of these are that long package names gets mangled > > in the yum output and i haven't found a place to tweak that. > > > > an EXCELLENT reason to never rely on screenscraping. A tool not designed to be connected with other tools? Sounds like a disregard for one of the best UNIX design principles, to me. Wil -- Wil Cooley Naked Ape Consulting, Ltd -------------- 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 Tue Dec 20 18:17:45 2005 From: denis at poolshark.org (Denis Leroy) Date: Tue, 20 Dec 2005 10:17:45 -0800 Subject: Too much time wasted installing fedora on raid1 In-Reply-To: <1135097822.3240.1.camel@localhost.localdomain> References: <20051219201653.GU1556@stingr.net> <1135026753.2947.23.camel@laptopd505.fenrus.org> <20051220085657.GW1556@stingr.net> <1135071978.2952.8.camel@laptopd505.fenrus.org> <20051220101303.GB23000@ryoko.camperquake.de> <1135097822.3240.1.camel@localhost.localdomain> Message-ID: <43A84AC9.5050906@poolshark.org> Peter Jones wrote: > On Tue, 2005-12-20 at 11:13 +0100, Ralf Ertzinger wrote: > >>On Tue, Dec 20, 2005 at 10:46:18AM +0100, Arjan van de Ven wrote: >> >> >>>well... if the root is brand spanking new.. why would it need a sync? >> >>Because it _is_ brand spanking new (and thus unclean from a RAID point >>of view)? > > > Why does that matter? The parts of it we've written data out to are > supposed to be in sync already. The resync should only be making the > parts that aren't in use yet identical. Exactly, it's like trying to sync uninitialized memory. Now i believe the --assume-clean option of mdadm only works for RAID1 unfortunately. Also, the layered approach of RAID is why RAID "just works", trying to build the redundancy into the filesystem itself would be pure madness. There are many excellent OS design books that will explain this much better than i ever could. From dmalcolm at redhat.com Tue Dec 20 18:59:33 2005 From: dmalcolm at redhat.com (David Malcolm) Date: Tue, 20 Dec 2005 13:59:33 -0500 Subject: rawhide report: 20051220 changes In-Reply-To: <200512200819.jBK8JoHM013990@porkchop.devel.redhat.com> References: <200512200819.jBK8JoHM013990@porkchop.devel.redhat.com> Message-ID: <1135105173.7158.80.camel@cassandra.boston.redhat.com> On Tue, 2005-12-20 at 03:19 -0500, Build System wrote: [snip] > Broken deps for i386 > ---------------------------------------------------------- [snip] > control-center - 1:2.13.3-1.i386 requires libedataserver-1.2.so.4 [snip] > evolution-webcal - 2.4.1-1.1.i386 requires libedataserver-1.2.so.4 > gaim - 1:1.5.0-9.fc5.1.i386 requires libedataserver-1.2.so.4 [snip] > gnome-panel - 2.13.3-1.i386 requires libedataserver-1.2.so.4 [snip] > gnomemeeting - 1.2.3-1.i386 requires libedataserver-1.2.so.4 [snip] > nautilus-sendto - 0.4-5.1.i386 requires libedataserver-1.2.so.4 [snip] Sorry about breaking the tree. Looks like all of these have now been rebuilt against the newer evolution-data-server, so rawhide should be in better shape tomorrow - or at least this part of it. Dave From jkeating at redhat.com Tue Dec 20 19:02:34 2005 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 20 Dec 2005 11:02:34 -0800 Subject: rawhide report: 20051220 changes In-Reply-To: <200512200819.jBK8JoHM013990@porkchop.devel.redhat.com> References: <200512200819.jBK8JoHM013990@porkchop.devel.redhat.com> Message-ID: <1135105354.4131.19.camel@yoda.loki.me> On Tue, 2005-12-20 at 03:19 -0500, Build System wrote: > gnome-python2-libgtop2 - 2.12.1-7.1.i386 requires libgtop-2.0.so.5 This has just been rebuilt and should be clean for tomorrows rawhide. With David Malcom's report that should leave just jacorb, jonas, and the various *-kernel packages as broken deps (well and whatever we manage to break today....) -- Jesse Keating Release Engineer: Fedora -------------- 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 dwalsh at redhat.com Tue Dec 20 19:22:07 2005 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 20 Dec 2005 14:22:07 -0500 Subject: yum scriptlet exit status 255 when su-ed to root (with selinux) In-Reply-To: <43A5A77B.6030105@hhs.nl> References: <43A53C35.9030901@hhs.nl> <604aa7910512180645n3f968eadn73540c96490c3bc0@mail.gmail.com> <43A5A77B.6030105@hhs.nl> Message-ID: <43A859DF.1080300@redhat.com> Hans de Goede wrote: > > > Jeff Spaleta wrote: >> On 12/18/05, Hans de Goede wrote: >>> Running yum when directly logged in as root from the console works >>> fine. >>> >>> Bugzilla? >> >> selinux issue most likely, look over the archives and bugzilla and >> relabel your filesystem >> > > Filesystem has already been relabeled, both manually and automaticly > on reboot, this only happened if I've done "su -" to root, not when > directly logged in as root. > > Regards, > > Hans > What policy are you running? -- From wtogami at redhat.com Tue Dec 20 19:23:10 2005 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Dec 2005 14:23:10 -0500 Subject: scim-libs not signed error when using yum?? In-Reply-To: <200512201737.jBKHbu4u014724@laptop11.inf.utfsm.cl> References: <200512201737.jBKHbu4u014724@laptop11.inf.utfsm.cl> Message-ID: <43A85A1E.2070701@redhat.com> Horst von Brand wrote: > Jens Petersen wrote: >> Gianluca Cecchi wrote: >>> Package scim-libs-1.4.2-9.i386.rpm is not signed > >> Packages in FC Devel are not usually signed (except for packages included >> from test releases). > > Could The Powers That Be consider signing the packages? Even with a > rawhide-only key? That way I'd sleep a little better, knowing I've got no > malicious gunk installed on my machine. It is possible that we can do this in the future after we implement a key piece of infrastructure, but until then it will remain unsigned like all past years of rawhide. I am pushing for signing of rawhide using a separate less trusted automatic signing key. It will happen one day... Warren Togami wtogami at redhat.com From pmatilai at laiskiainen.org Tue Dec 20 19:34:46 2005 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Tue, 20 Dec 2005 21:34:46 +0200 Subject: "yum --partial" feature as a bash line In-Reply-To: <1135102350.24626.9.camel@willow.odshp.com> References: <439C0C8A.9090002@interia.pl> <1134517049.28114.65.camel@willow.odshp.com> <1134683461.26513.6.camel@cutter> <1135102350.24626.9.camel@willow.odshp.com> Message-ID: <43A85CD6.2070507@laiskiainen.org> Wil Cooley wrote: > On Thu, 2005-12-15 at 16:51 -0500, seth vidal wrote: > > >>>The problem with any of these are that long package names gets mangled >>>in the yum output and i haven't found a place to tweak that. >>> >> >>an EXCELLENT reason to never rely on screenscraping. > > > A tool not designed to be connected with other tools? Sounds like a > disregard for one of the best UNIX design principles, to me. Yum is more of an interactive program than a tool designed to be piped into something else - users want a nicely formatted output where the update is coming from, progress bars and such, all of which pretty much conflicts with piping to other programs (hence the "screen scraping" term). You might want to try it with something that lets you format the output to your liking, for example ""repoquery --pkgnarrow=updates -a" and apply --queryformat to your liking. - Panu - From walovaton at yahoo.com.mx Tue Dec 20 19:43:30 2005 From: walovaton at yahoo.com.mx (William Lovaton) Date: Tue, 20 Dec 2005 13:43:30 -0600 (CST) Subject: How to update from FC4 to RawHide Message-ID: <20051220194330.15424.qmail@web60712.mail.yahoo.com> Hello there, I'm trying to update to RawHide from an up to date FC4 system. I got this conflicts: Error: Unable to satisfy dependencies Error: Package initscripts needs kernel < 2.6.12, this is not available. Error: Package kudzu needs kernel < 2.6.13, this is not available. How can I fix this? I guess this is due to the latest updates in rawhide. BTW, what is the best way to install rawhide? Thanx, -William ___________________________________________________________ Do You Yahoo!? La mejor conexi?n a Internet y 2GB extra a tu correo por $100 al mes. http://net.yahoo.com.mx From gianluca.cecchi at gmail.com Tue Dec 20 19:47:34 2005 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Tue, 20 Dec 2005 20:47:34 +0100 Subject: yum problems when multiple kernels installed Message-ID: <561c252c0512201147u36f9f7f1w@mail.gmail.com> Hello, my situation is this: rpm -qa|grep kernel gives: kernel-smp-2.6.14-1.1771_FC5 kernel-2.6.14-1.1773_FC5 kernel-smp-2.6.14-1.1773_FC5 kernel-2.6.14-1.1771_FC5 in the local directory ls -1 kernel* kernel-2.6.14-1.1773_FC5.i586.rpm kernel-2.6.14-1.1773_FC5.i686.rpm kernel-devel-2.6.14-1.1773_FC5.i586.rpm kernel-devel-2.6.14-1.1773_FC5.i686.rpm kernel-doc-2.6.14-1.1773_FC5.noarch.rpm kernel-smp-2.6.14-1.1773_FC5.i686.rpm kernel-smp-devel-2.6.14-1.1773_FC5.i686.rpm kernel-xen-guest-2.6.12-1.13_FC5.i686.rpm kernel-xen-guest-devel-2.6.12-1.13_FC5.i686.rpm kernel-xen-hypervisor-2.6.12-1.13_FC5.i686.rpm kernel-xen-hypervisor-devel-2.6.12-1.13_FC5.i686.rpm command yum localupdate *rpm at the end I have: ============================================================================= Installing: kernel i686 2.6.14-1.1773_FC5 kernel-2.6.14-1.1773_FC5.i686.rpm 33 M kernel-smp i686 2.6.14-1.1773_FC5 kernel-smp-2.6.14-1.1773_FC5.i686.rpm 38 M Removing: kernel i686 2.6.14-1.1771_FC5 installed 33 M kernel-smp i686 2.6.14-1.1771_FC5 installed 38 M Transaction Summary ============================================================================= Install 2 Package(s) Update 0 Package(s) Remove 2 Package(s) Total download size: 70 M Is this ok [y/N]: y Downloading Packages: Running Transaction Test Finished Transaction Test Transaction Check Error: package kernel-2.6.14-1.1773_FC5 is already installed package kernel-smp-2.6.14-1.1773_FC5 is already installed It seems yum is not able to manage where multiple versions of kernel are installed I would expect a message like "nothing to be updated". Gianluca -------------- next part -------------- An HTML attachment was scrubbed... URL: From davej at redhat.com Tue Dec 20 19:51:00 2005 From: davej at redhat.com (Dave Jones) Date: Tue, 20 Dec 2005 14:51:00 -0500 Subject: How to update from FC4 to RawHide In-Reply-To: <20051220194330.15424.qmail@web60712.mail.yahoo.com> References: <20051220194330.15424.qmail@web60712.mail.yahoo.com> Message-ID: <20051220195100.GH9251@redhat.com> On Tue, Dec 20, 2005 at 01:43:30PM -0600, William Lovaton wrote: > Hello there, > > I'm trying to update to RawHide from an up to date FC4 > system. I got this conflicts: > > Error: Unable to satisfy dependencies > Error: Package initscripts needs kernel < 2.6.12, this > is not available. > Error: Package kudzu needs kernel < 2.6.13, this is > not available. > > How can I fix this? I guess this is due to the latest > updates in rawhide. > > BTW, what is the best way to install rawhide? yum update to the latest fc4 kernel reboot into 2.6.14-1.1653_FC4 rpm -e all kernels lower than that revision yum update to rawhide. Dave From jspaleta at gmail.com Tue Dec 20 19:52:51 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Tue, 20 Dec 2005 14:52:51 -0500 Subject: yum problems when multiple kernels installed In-Reply-To: <561c252c0512201147u36f9f7f1w@mail.gmail.com> References: <561c252c0512201147u36f9f7f1w@mail.gmail.com> Message-ID: <604aa7910512201152w2de25b50i2767489eed603166@mail.gmail.com> On 12/20/05, Gianluca Cecchi wrote: > It seems yum is not able to manage where multiple versions of kernel are > installed > I would expect a message like "nothing to be updated". Sounds like a localupdate/localinstall bug when working with packages that are classified as "installonly" like kernel and kernel-smp. You should probably file this in bugzilla if its not already filed. Does localupdate work as you expect and give you a "nothing to update" message when you try to update something which is already installed other than a kernel via localupdate? -jef From linville at redhat.com Tue Dec 20 19:55:56 2005 From: linville at redhat.com (John W. Linville) Date: Tue, 20 Dec 2005 14:55:56 -0500 Subject: kernel-2.6.14-1.1653_FC4.netdev.6? In-Reply-To: <1135098078.3240.3.camel@localhost.localdomain> References: <43A05044.7060803@cygnusx-1.org> <20051215005152.GF26108@rathann.pekin.waw.pl> <20051215010803.GE9801@redhat.com> <20051215162712.GC16712@redhat.com> <20051215215952.GC4336@rathann.pekin.waw.pl> <20051216131221.GA9708@redhat.com> <20051216225617.GC4376@rathann.pekin.waw.pl> <20051219224322.GA5815@rathann.pekin.waw.pl> <1135098078.3240.3.camel@localhost.localdomain> Message-ID: <20051220195556.GB7693@redhat.com> On Tue, Dec 20, 2005 at 12:01:17PM -0500, Peter Jones wrote: > On Mon, 2005-12-19 at 23:43 +0100, Dominik 'Rathann' Mierzejewski wrote: > > > Additionally, I can't turn on debugging. modprobe ipw2200 debug=0xffff > > output is no more verbose than without the debug option. > > With which kernel? I turned CONFIG_IPW_DEBUG back on several days > ago... The corresponding CONFIG_IPW2100_DEBUG and CONFIG_IPW2200_DEBUG are probably off in the netdev.6 kernel, iirc. John -- John W. Linville linville at redhat.com From gianluca.cecchi at gmail.com Tue Dec 20 20:04:48 2005 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Tue, 20 Dec 2005 21:04:48 +0100 Subject: yum problems when multiple kernels installed Message-ID: <561c252c0512201204x1b8f98caw@mail.gmail.com> >Does localupdate work as you expect and give you a "nothing to >update" message when you try to update something which is already >installed other than a kernel via localupdate? It seems it works: ls -1| grep -v ^kernel > /tmp/list yum localupdate $(cat /tmp/list) xterm-207-8.i386.rpm: does not update installed package. yelp-2.13.2-2.i386.rpm: does not update installed package. ypbind-1.17.2-5.1.i386.rpm: does not update installed package. yp-tools-2.8-8.1.i386.rpm: does not update installed package. yum-2.5.0-4.noarch.rpm: does not update installed package. zip-2.31-1.1.i386.rpm: does not update installed package. zisofs-tools-1.0.6-3.1.i386.rpm: does not update installed package. zlib-1.2.3-1.1.i386.rpm: does not update installed package. zlib-devel-1.2.3-1.1.i386.rpm: does not update installed package. zsh-4.2.5-1.i386.rpm: does not update installed package. Nothing to do Eventually I will file a bug (I will learn ho to...) Gianluca -------------- next part -------------- An HTML attachment was scrubbed... URL: From walovaton at yahoo.com.mx Tue Dec 20 20:19:51 2005 From: walovaton at yahoo.com.mx (William Lovaton) Date: Tue, 20 Dec 2005 14:19:51 -0600 (CST) Subject: How to update from FC4 to RawHide In-Reply-To: <20051220195100.GH9251@redhat.com> Message-ID: <20051220201951.72528.qmail@web60713.mail.yahoo.com> --- Dave Jones escribi?: > On Tue, Dec 20, 2005 at 01:43:30PM -0600, William > Lovaton wrote: > > Hello there, > > > > I'm trying to update to RawHide from an up to > date FC4 > > system. I got this conflicts: > > > > Error: Unable to satisfy dependencies > > Error: Package initscripts needs kernel < 2.6.12, > this > > is not available. > > Error: Package kudzu needs kernel < 2.6.13, this > is > > not available. > > > > How can I fix this? I guess this is due to the > latest > > updates in rawhide. > > > > BTW, what is the best way to install rawhide? > > yum update to the latest fc4 kernel > reboot into 2.6.14-1.1653_FC4 > rpm -e all kernels lower than that revision > yum update to rawhide. > > Dave That did the trick, I'm downloading the updates right now :-) Thanx a lot Dave. -William ___________________________________________________________ Do You Yahoo!? La mejor conexi?n a Internet y 2GB extra a tu correo por $100 al mes. http://net.yahoo.com.mx From alan at redhat.com Tue Dec 20 20:21:21 2005 From: alan at redhat.com (Alan Cox) Date: Tue, 20 Dec 2005 15:21:21 -0500 Subject: bittorrent in core? what frontend? In-Reply-To: <1134979247.28842.210.camel@greebo> References: <1134662961.28842.128.camel@greebo> <20051215202126.GA4210@devserv.devel.redhat.com> <1134721846.28842.166.camel@greebo> <20051217070856.GD24500@devserv.devel.redhat.com> <1134979247.28842.210.camel@greebo> Message-ID: <20051220202121.GA11608@devserv.devel.redhat.com> On Mon, Dec 19, 2005 at 09:00:47AM +0100, Alexander Larsson wrote: > I think the standard ui client looks fine for "just clicked on > a .torrent file" actually. I'm not sure gnome-bt is better for this. Does the standard UI include accessibility hooks ? From geraldlt at gmail.com Tue Dec 20 20:37:23 2005 From: geraldlt at gmail.com (Gerald Thompson) Date: Tue, 20 Dec 2005 13:37:23 -0700 Subject: bittorrent in core? what frontend? In-Reply-To: <1134662961.28842.128.camel@greebo> References: <1134662961.28842.128.camel@greebo> Message-ID: <4d57abbe0512201237k3021fca6m9931727408a634fe@mail.gmail.com> On 12/15/05, Alexander Larsson wrote: > At some point in time we in the desktop group discussed shipping > bittorrent and a nice frontend in fedora core. Since more and more > people start to use this as a standard way of distributing software > (e.g. fedora core itself uses this) it really should be supported in a > default desktop install, so that when you click on a torrent file in the > browser something "nice" happens. > > What are peoples opinions on this? > > Another question is what frontend to use as a default. bittorrent itself > ships with a wxPython based frontend (bittorrent-gui, availible with > bittorrent in fedora extras). Another frontend is gnome-bt > (http://gnome-bt.sourceforge.net/) which is designed more like a simple > *.torrent mime handler rather than a full bittorrent app. Ubuntu > defaults to this i think. > > I packaged gnome-bt at: > http://people.redhat.com/alexl/files/gnome-bt-0.0.22-1.noarch.rpm > http://people.redhat.com/alexl/files/gnome-bt-0.0.22-1.src.rpm > > I don't use bittorrent all that much. What do people think about these > two frontends? Are there other interesting ones? > If you are going to package a client with the OS make it bittorrent-gui - I actually used this for a while because azureus is kind of a resource hog sometimes. Azureus is working a bit better now since the latest update so I switched back. For simplicity bittorrent-gui works fine and it also manages the upload ratio quite well actually. If you feel the need to do so you can actually tell bittorrent-gui to keep seeding any of the files indefinately if you are trying to get your share ratio up. At one point I had 5 items set to seed indefinately while I was downloading a few others. It is nowhere near as powerful as azureus but it is a decent simple program. Since the 4.2 update bittorrent-gui became even more customizable, although people have to realize they need to right-click on the torrent to access some of the extra features like seed indefinately. Sincerely, -- Gerald Thompson geraldlt at gmail.com www.gltechsolutions.com From n0dalus+redhat at gmail.com Tue Dec 20 21:28:59 2005 From: n0dalus+redhat at gmail.com (n0dalus) Date: Wed, 21 Dec 2005 07:58:59 +1030 Subject: "yum --partial" feature as a bash line In-Reply-To: <43A85CD6.2070507@laiskiainen.org> References: <439C0C8A.9090002@interia.pl> <1134517049.28114.65.camel@willow.odshp.com> <1134683461.26513.6.camel@cutter> <1135102350.24626.9.camel@willow.odshp.com> <43A85CD6.2070507@laiskiainen.org> Message-ID: <6280325c0512201328o5697c419wcd388b5587f6f11c@mail.gmail.com> On 12/21/05, Panu Matilainen wrote: > Wil Cooley wrote: > > On Thu, 2005-12-15 at 16:51 -0500, seth vidal wrote: > > > > > >>>The problem with any of these are that long package names gets mangled > >>>in the yum output and i haven't found a place to tweak that. > >>> > >> > >>an EXCELLENT reason to never rely on screenscraping. > > > > > > A tool not designed to be connected with other tools? Sounds like a > > disregard for one of the best UNIX design principles, to me. > > Yum is more of an interactive program than a tool designed to be piped > into something else - users want a nicely formatted output where the > update is coming from, progress bars and such, all of which pretty much > conflicts with piping to other programs (hence the "screen scraping" term). Just because yum is interactive doesn't mean it shouldn't handle screen wrapping properly. Notice how `ls` (at least on my system) shows the results in columns with colours, but when you pipe it, it automatically outputs as a list without colours. I think this is to do with detecting the usage of /dev/tty or something (I can't remember). If python is not capable of doing that kind of thing I would be surprised. n0dalus. From ottohaliburton at comcast.net Tue Dec 20 21:59:10 2005 From: ottohaliburton at comcast.net (Otto Haliburton) Date: Tue, 20 Dec 2005 15:59:10 -0600 Subject: Everything installs (was: yum downloads need revamping) In-Reply-To: <1135102281.3445.17.camel@mentorng.gurulabs.com> References: <1135090361.3631.3.camel@c515816-a> <604aa7910512200706u1fcc7fdasfa8465172c235624@mail.gmail.com> <1135092644.3631.12.camel@c515816-a> <604aa7910512200748w6a00b7f6n4fc7a1c20363a93e@mail.gmail.com> <1135102281.3445.17.camel@mentorng.gurulabs.com> Message-ID: <1135115950.3623.6.camel@c515816-a> On Tue, 2005-12-20 at 11:11 -0700, Dax Kelson wrote: > On Tue, 2005-12-20 at 10:48 -0500, Jeff Spaleta wrote: > > On 12/20/05, Otto Haliburton wrote: > > > well, i can agree with you if fedora was a production system, as far as > > > I know it is a development system and the object is to select a complete > > > download, > > > > Pretty sure noone sane thinks an "everything" install is a good idea. > > But you are free to continue to attempt them. > > For a "production" box (server) that is performing some defined task(s), > I agree that "everything" is a bad idea. > > For a "power user"/developer box, I don't see any problem with an > "everything" install. Hard disk space is cheap and you can find some > cool apps you may not have found otherwise. > > Additionally, I can recall some situations where an application > dynamically gets extra functionality and features if other *addon* or > *plugin* packages get installed. > > For example, unless you have "kdeaddons" RPM installed the Konqueror > browser doesn't have the ability to save a web page offline in a > tarball. The menu item doesn't show up at all, what a mystery for > someone not familiar with low level KDE interactions. When I discovered > this a couple years ago the only way to get the "kdeaddons" RPMs > installed during installation was via an "everything" install. Possibly > this has changed now. > > Personally, I prefer an "Mostly english-only everything install" on my > personal boxes. I do an "everything" install, and first thing after the > install finishes I run: > > # trim some fat (1.1GB worth) > rpm -e `rpm -qa | grep ^openoffice.org-langpack` # 600MB > rpm -e `rpm -qa | grep ^kde-i18n` # 400MB > rpm -e `rpm -qa | grep -E ^man-pages-[[:alpha:]]` # 100MB > > This may be helpful to the original poster. > > Dax Kelson > Guru Labs > the possible solution is noted. I am going to toss this out and I know that it has been suggested many times, and that is that a graphical interface be created for yum. This has both a good and a bad component, which could be solved by having a standalone yum and a graphical interface to the stand along version. Up2date seems to function as one but I believe it has been effectively disabled in fc4. This is a suggestion but maybe a development thing for the future. -- Otto Haliburton From lamont at gurulabs.com Tue Dec 20 22:10:22 2005 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Tue, 20 Dec 2005 15:10:22 -0700 Subject: YUM repository precedence RFE Message-ID: <200512201510.27042.lamont@gurulabs.com> All, I'm suggesting an enhancement to yum so that one could configure "priorities" or a "precedence" (preference) order for multiple repositories. For example, I could say that I want packages from repo Y to be used even if there are newer versions in repo X. This would allow one to build customized repos that only contain the small subset of packages that need customization, even if those packages exist in the base repo, Fedora Extras, Dag, etc. I think that this will make it easier to deal with building and maintaining local-use mirrors, like I have at home, as well as other more widely used mirrors (like kde-redhat, for example). The implementation should be very simple. If the "precedence" variable exists in the .repo file, use that number to sort out which repo's packages to use in cases where there is duplication. Thoughts? -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] -------------- 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 j2solutions.net Tue Dec 20 22:18:30 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 20 Dec 2005 14:18:30 -0800 Subject: YUM repository precedence RFE In-Reply-To: <200512201510.27042.lamont@gurulabs.com> References: <200512201510.27042.lamont@gurulabs.com> Message-ID: <1135117110.4131.47.camel@yoda.loki.me> On Tue, 2005-12-20 at 15:10 -0700, Lamont R. Peterson wrote: > Thoughts? This is an upstream yum thing. Yum is used by more than just Fedora, so it is appropriate to make this sort of suggestion upstream on the yum development list. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 seandarcy2 at gmail.com Tue Dec 20 23:28:49 2005 From: seandarcy2 at gmail.com (sean) Date: Tue, 20 Dec 2005 18:28:49 -0500 Subject: something's uninstalling the sun jre, again Message-ID: I installed jre-1_5_0_06-linux-i586.rpm from sun about two weeks ago. It's gone now. Oddly, there's no other package called jre, at least on my box, but something's not playing nicely with others. sean From jkeating at j2solutions.net Tue Dec 20 23:36:03 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Tue, 20 Dec 2005 15:36:03 -0800 Subject: something's uninstalling the sun jre, again In-Reply-To: References: Message-ID: <1135121763.4131.50.camel@yoda.loki.me> On Tue, 2005-12-20 at 18:28 -0500, sean wrote: > I installed jre-1_5_0_06-linux-i586.rpm from sun about two > weeks ago. > > It's gone now. > > Oddly, there's no other package called jre, at least on my > box, but something's not playing nicely with others. It is possible that the free java is obsoleting or otherwise conflicting with the sun java. java-1.4.2-gcj-compat-1.4.2.0-40jpp_56rh.1.1.i386.rpm -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 Tue Dec 20 23:43:08 2005 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 20 Dec 2005 15:43:08 -0800 Subject: Plan for the Holidays Message-ID: <1135122188.10390.3.camel@yoda.loki.me> With the holidays upcoming, I plan to get the devel tree as broken-dep free as possible. This includes the foo-kernel packages. I'll be trying to keep those in sync with the new kernels that are pushed into rawhide. A lot of folks will have time off over the next couple weeks and if they choose to test stuff I'd like it to be as easy as possible. That said, I think it would be good for developers to post what specifically they think should be tested during this time. What components do we need some extra eyes on as we approach test2 freeze? Off the top of my head, we need the java stack tested, and that is a pretty big thing. Also the functionality of your favorite apps is a good thing to target, given that everything has been rebuilt with the new gcc. So Developers? What would you like the masses to test? -- Jesse Keating Release Engineer: Fedora -------------- 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 reuben-fedora-devel at reub.net Wed Dec 21 00:02:38 2005 From: reuben-fedora-devel at reub.net (Reuben Farrelly) Date: Wed, 21 Dec 2005 11:02:38 +1100 Subject: Plan for the Holidays In-Reply-To: <1135122188.10390.3.camel@yoda.loki.me> References: <1135122188.10390.3.camel@yoda.loki.me> Message-ID: <43A89B9E.7060203@reub.net> On 21/12/2005 10:43 a.m., Jesse Keating wrote: > With the holidays upcoming, I plan to get the devel tree as broken-dep > free as possible. This includes the foo-kernel packages. I'll be > trying to keep those in sync with the new kernels that are pushed into > rawhide. A lot of folks will have time off over the next couple weeks > and if they choose to test stuff I'd like it to be as easy as possible. > > That said, I think it would be good for developers to post what > specifically they think should be tested during this time. What > components do we need some extra eyes on as we approach test2 freeze? > > Off the top of my head, we need the java stack tested, and that is a > pretty big thing. Also the functionality of your favorite apps is a > good thing to target, given that everything has been rebuilt with the > new gcc. A whole lot of stuff in -extras development hasn't been rebuilt for months and months either - some as far back as March/April (look at perl-* modules in extras for an example). No doubt there are various dependency issues there too. Can this be looked at as well? I'm sure packages in extras would also benefit from a rebuild with newer gcc and therefore wider testing over the break. Extras really does look like a second rate citizen if everything in rawhide is rebuilt for a new gc(c|j)/openssl but packages in extras are left untouched for months... reuben From jkeating at redhat.com Wed Dec 21 00:14:07 2005 From: jkeating at redhat.com (Jesse Keating) Date: Tue, 20 Dec 2005 16:14:07 -0800 Subject: Plan for the Holidays In-Reply-To: <43A89B9E.7060203@reub.net> References: <1135122188.10390.3.camel@yoda.loki.me> <43A89B9E.7060203@reub.net> Message-ID: <1135124047.10390.12.camel@yoda.loki.me> On Wed, 2005-12-21 at 11:02 +1100, Reuben Farrelly wrote: > A whole lot of stuff in -extras development hasn't been rebuilt for months and > months either - some as far back as March/April (look at perl-* modules in > extras for an example). No doubt there are various dependency issues there too. > > Can this be looked at as well? I'm sure packages in extras would also benefit > from a rebuild with newer gcc and therefore wider testing over the break. > > Extras really does look like a second rate citizen if everything in rawhide is > rebuilt for a new gc(c|j)/openssl but packages in extras are left untouched for > months... Extras is maintained by the individual package maintainers. It is up to them to keep their packages updated. This is usually the way it works inside Red Hat as well, however when we release a new GCC so close to the freeze date, I step in to autobump the packages when possible. There isn't really somebody to do this for all of Extras, nor would extras maintainers be all that welcome for it as a whole. Extras tracking rawhide is pretty tough as things change so rapidly. However during the holidays would be a good time for extras maintainers to rebase their packages off the current rawhide. Also during the freeze and just after a test release would be another good time for Extras maintainers to rebuild their packages. Extras is only as second rate as the maintainers (community) makes it. -- Jesse Keating Release Engineer: Fedora -------------- 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 dominik at greysector.net Wed Dec 21 01:32:26 2005 From: dominik at greysector.net (Dominik 'Rathann' Mierzejewski) Date: Wed, 21 Dec 2005 02:32:26 +0100 Subject: kernel-2.6.14-1.1653_FC4.netdev.6? In-Reply-To: <1135098078.3240.3.camel@localhost.localdomain> References: <43A05044.7060803@cygnusx-1.org> <20051215005152.GF26108@rathann.pekin.waw.pl> <20051215010803.GE9801@redhat.com> <20051215162712.GC16712@redhat.com> <20051215215952.GC4336@rathann.pekin.waw.pl> <20051216131221.GA9708@redhat.com> <20051216225617.GC4376@rathann.pekin.waw.pl> <20051219224322.GA5815@rathann.pekin.waw.pl> <1135098078.3240.3.camel@localhost.localdomain> Message-ID: <20051221013226.GA5096@rathann.pekin.waw.pl> On Tuesday, 20 December 2005 at 18:01, Peter Jones wrote: > On Mon, 2005-12-19 at 23:43 +0100, Dominik 'Rathann' Mierzejewski wrote: > > > Additionally, I can't turn on debugging. modprobe ipw2200 debug=0xffff > > output is no more verbose than without the debug option. > > With which kernel? I turned CONFIG_IPW_DEBUG back on several days > ago... John's. And he already said it's disabled in his. *sigh* I guess it's recompile time again. ;) R. -- APT/YUM RPM repository for Fedora Core http://rpm.greysector.net/ mpg321, xmp, faad2, lame, mad, *mplayer*, rdesktop, tin, xvid, mks, mutt "Faith manages." -- Delenn to Lennier in Babylon 5:"Confessions and Lamentations" From wtogami at redhat.com Wed Dec 21 03:13:46 2005 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Dec 2005 22:13:46 -0500 Subject: something's uninstalling the sun jre, again In-Reply-To: <1135121763.4131.50.camel@yoda.loki.me> References: <1135121763.4131.50.camel@yoda.loki.me> Message-ID: <43A8C86A.2040308@redhat.com> Jesse Keating wrote: > On Tue, 2005-12-20 at 18:28 -0500, sean wrote: >> I installed jre-1_5_0_06-linux-i586.rpm from sun about two >> weeks ago. >> >> It's gone now. >> >> Oddly, there's no other package called jre, at least on my >> box, but something's not playing nicely with others. > > It is possible that the free java is obsoleting or otherwise conflicting > with the sun java. > > java-1.4.2-gcj-compat-1.4.2.0-40jpp_56rh.1.1.i386.rpm > > Yes, this is because Sun is not cooperating with the community on RPM packaging standards. If you want a Sun java RPM that integrates well into Fedora, you should build one from jpackage.org. Warren Togami wtogami at redhat.com From wtogami at redhat.com Wed Dec 21 03:16:22 2005 From: wtogami at redhat.com (Warren Togami) Date: Tue, 20 Dec 2005 22:16:22 -0500 Subject: Plan for the Holidays In-Reply-To: <1135124047.10390.12.camel@yoda.loki.me> References: <1135122188.10390.3.camel@yoda.loki.me> <43A89B9E.7060203@reub.net> <1135124047.10390.12.camel@yoda.loki.me> Message-ID: <43A8C906.4080001@redhat.com> Jesse Keating wrote: >> >> Extras really does look like a second rate citizen if everything in rawhide is >> rebuilt for a new gc(c|j)/openssl but packages in extras are left untouched for >> months... > > Extras is only as second rate as the maintainers (community) makes it. > Well put. And unfortunately extras buildsys depends on the deps in Core to be consistent, so many days we were unable to build recently after the relative chaos of the gcc-4.1 change. Hopefully things will begin to settle down now. Warren Togami wtogami at redhat.com From rodd at clarkson.id.au Wed Dec 21 03:25:47 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Wed, 21 Dec 2005 14:25:47 +1100 Subject: Plan for the Holidays In-Reply-To: <1135122188.10390.3.camel@yoda.loki.me> References: <1135122188.10390.3.camel@yoda.loki.me> Message-ID: <1135135547.3149.11.camel@localhost.localdomain> On Tue, 2005-12-20 at 15:43 -0800, Jesse Keating wrote: > With the holidays upcoming, I plan to get the devel tree as broken-dep > free as possible. This includes the foo-kernel packages. I'll be > trying to keep those in sync with the new kernels that are pushed into > rawhide. A lot of folks will have time off over the next couple weeks > and if they choose to test stuff I'd like it to be as easy as possible. > > That said, I think it would be good for developers to post what > specifically they think should be tested during this time. What > components do we need some extra eyes on as we approach test2 freeze? > > Off the top of my head, we need the java stack tested, and that is a > pretty big thing. Also the functionality of your favorite apps is a > good thing to target, given that everything has been rebuilt with the > new gcc. > > So Developers? What would you like the masses to test? I'd like to see gpilotd and pilot-link working with my palm zire 72. While everyone seems to agree that it should just work, it hasn't for me and I've tried it on both FC4 and rawhide. I know this might be trivial, but it's something that doesn't work and should. R. -- "It's a fine line between denial and faith. It's much better on my side" From rodd at clarkson.id.au Wed Dec 21 03:39:00 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Wed, 21 Dec 2005 14:39:00 +1100 Subject: Plan for the Holidays In-Reply-To: <1135122188.10390.3.camel@yoda.loki.me> References: <1135122188.10390.3.camel@yoda.loki.me> Message-ID: <1135136340.3149.13.camel@localhost.localdomain> On Tue, 2005-12-20 at 15:43 -0800, Jesse Keating wrote: > With the holidays upcoming, I plan to get the devel tree as broken-dep > free as possible. This includes the foo-kernel packages. I'll be > trying to keep those in sync with the new kernels that are pushed into > rawhide. A lot of folks will have time off over the next couple weeks > and if they choose to test stuff I'd like it to be as easy as possible. > > That said, I think it would be good for developers to post what > specifically they think should be tested during this time. What > components do we need some extra eyes on as we approach test2 freeze? > > Off the top of my head, we need the java stack tested, and that is a > pretty big thing. Also the functionality of your favorite apps is a > good thing to target, given that everything has been rebuilt with the > new gcc. > > So Developers? What would you like the masses to test? I'd like to see gpilotd and pilot-link working with my palm zire 72. While everyone seems to agree that it should just work, it hasn't for me and I've tried it on both FC4 and rawhide. I know this might be trivial, but it's something that doesn't work and should. R. -- "It's a fine line between denial and faith. It's much better on my side" -- "It's a fine line between denial and faith. It's much better on my side" From bernie at develer.com Wed Dec 21 03:42:17 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Wed, 21 Dec 2005 04:42:17 +0100 Subject: Enable sqlite database backend in QT Message-ID: <43A8CF19.6070909@develer.com> Hello, the sqlite plugin for Qt isn't built on Fedora. Unless there's a good reason, I'd like to propose the following spec change to create the missing package. Patch by Lorenzo Mancini . --- SPECS/qt.spec.orig 2005-12-20 23:58:40.000000000 +0100 +++ SPECS/qt.spec 2005-12-21 01:38:20.000000000 +0100 @@ -31,6 +31,9 @@ # buildodbc: Build ODBC plugins %define buildodbc 1 +# buildsqlite: Build SQLite plugins +%define buildsqlite 1 + # buildmt: Build libs with threading support %define buildmt 1 @@ -77,7 +80,13 @@ %define plugin_odbc %{nil} %endif -%define plugins %{plugin_mysql} %{plugin_psql} %{plugin_odbc} %{plugins_style} +%if %{buildsqlite} +%define plugin_sqlite -plugin-sql-sqlite +%else +%define plugin_sqlite %{nil} +%endif + +%define plugins %{plugin_mysql} %{plugin_psql} %{plugin_odbc} %{plugin_sqlite} %{plugins_style} Summary: The shared library for the Qt GUI toolkit. Name: qt @@ -169,6 +178,10 @@ BuildRequires: unixODBC-devel %endif +%if %{buildsqlite} +BuildRequires: sqlite2-devel +%endif + BuildRequires: fontconfig-devel >= 2.0 @@ -224,6 +237,14 @@ %endif +%if %{buildsqlite} +%package SQLite +Summary: SQLite drivers for Qt's SQL classes. +Group: System Environment/Libraries +Requires: %{name} = %{epoch}:%{version}-%{release} +%endif + + %package static Summary: Version of the Qt GUI toolkit for static linking Group: Development/Libraries @@ -296,6 +317,10 @@ PostgreSQL driver for Qt's SQL classes (QSQL) %endif +%if %{buildsqlite} +%description SQLite +SQLite driver for Qt's SQL classes (QSQL) +%endif %description designer The qt-designer package contains an User Interface designer tool @@ -447,6 +472,13 @@ popd %endif +# build sqlite plugin +%if %{buildsqlite} + pushd plugins/src/sqldrivers/sqlite + qmake -o Makefile "LIBS+=-lsqlite" sqlite.pro + popd +%endif + make $SMP_MFLAGS src-moc make $SMP_MFLAGS sub-src make $SMP_MFLAGS sub-tools UIC="$QTDIR/bin/uic -nostdlib -L $QTDIR/plugins" @@ -693,6 +725,11 @@ %{qtdir}/plugins/sqldrivers/libqsqlmysql* %endif +%if %{buildsqlite} +%files SQLite +%defattr(-,root,root,-) +%{qtdir}/plugins/sqldrivers/libqsqlite* +%endif %files designer %defattr(-,root,root,-) -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From lists at ralii.com Wed Dec 21 05:04:20 2005 From: lists at ralii.com (Robert Locke) Date: Wed, 21 Dec 2005 00:04:20 -0500 Subject: Plan for the Holidays In-Reply-To: <1135136340.3149.13.camel@localhost.localdomain> References: <1135122188.10390.3.camel@yoda.loki.me> <1135136340.3149.13.camel@localhost.localdomain> Message-ID: <1135141460.2763.10.camel@rltp40f4.ralii.com> On Wed, 2005-12-21 at 14:39 +1100, Rodd Clarkson wrote: > On Tue, 2005-12-20 at 15:43 -0800, Jesse Keating wrote: > > With the holidays upcoming, I plan to get the devel tree as broken-dep > > free as possible. This includes the foo-kernel packages. I'll be > > trying to keep those in sync with the new kernels that are pushed into > > rawhide. A lot of folks will have time off over the next couple weeks > > and if they choose to test stuff I'd like it to be as easy as possible. > > > > That said, I think it would be good for developers to post what > > specifically they think should be tested during this time. What > > components do we need some extra eyes on as we approach test2 freeze? > > > > Off the top of my head, we need the java stack tested, and that is a > > pretty big thing. Also the functionality of your favorite apps is a > > good thing to target, given that everything has been rebuilt with the > > new gcc. > > > > So Developers? What would you like the masses to test? > > I'd like to see gpilotd and pilot-link working with my palm zire 72. > While everyone seems to agree that it should just work, it hasn't for me > and I've tried it on both FC4 and rawhide. > > I know this might be trivial, but it's something that doesn't work and > should. > > I'll request a +1 on this. Though I am not sure how "ready" gpilotd is yet. I heard that some commits were made to gnome-pilot cvs to support 0.12 of pilot-link but do not know if it is truly working. Have also heard reports of people having success with the rpm's for gnome-pilot being hosted at: http://zeniv.linux.org.uk/pub/people/mark_adams/ Personally I am just using pilot-link to back up my Treo and waiting til things settle out on gnome-pilot to get it back in Evolution.... --Rob From mpeters at mac.com Wed Dec 21 05:58:59 2005 From: mpeters at mac.com (Michael A. Peters) Date: Tue, 20 Dec 2005 21:58:59 -0800 Subject: Plan for the Holidays In-Reply-To: <43A89B9E.7060203@reub.net> References: <1135122188.10390.3.camel@yoda.loki.me> <43A89B9E.7060203@reub.net> Message-ID: <1135144739.3972.2.camel@locolhost.localdomain> On Wed, 2005-12-21 at 11:02 +1100, Reuben Farrelly wrote: > > A whole lot of stuff in -extras development hasn't been rebuilt for months and > months either - some as far back as March/April (look at perl-* modules in > extras for an example). No doubt there are various dependency issues there too. > > Can this be looked at as well? I'm sure packages in extras would also benefit > from a rebuild with newer gcc and therefore wider testing over the break. Definitely. Especially the c++ packages. From buildsys at redhat.com Wed Dec 21 08:21:31 2005 From: buildsys at redhat.com (Build System) Date: Wed, 21 Dec 2005 03:21:31 -0500 Subject: rawhide report: 20051221 changes Message-ID: <200512210821.jBL8LV9F025297@porkchop.devel.redhat.com> New package perl-String-CRC32 Perl interface for cyclic redundency check generation Updated Packages: SysVinit-2.86-1 --------------- * Mon Dec 19 2005 Bill Nottingham - 2.86-1 - update to upstream 2.86 - adjust patches - install initreq.h (#119039) - allow halt/reboot to handle being called by login correctly (#104062, ) - document pam_console usage for halt (#114970) * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj * Mon Dec 05 2005 Dan Walsh - 2.85-43 - Use log(L_VB for SELinux error anaconda-10.90.23-1 ------------------- * Tue Dec 20 2005 Jeremy Katz - 10.90.23-1 - more pkgorder fixes (pnasrat) - fix some debug spew (notting) - segfaults in the loader should at least give us a stacktrace to work from - fix some padding on the network screen bind-28:9.3.2rc1-2 ------------------ * Tue Dec 20 2005 Jason Vas Dias - 28:9.3.2rc1-2 - fix bug 176100: do not Require: perl just for namedGetForwarders ! control-center-1:2.13.3-2 ------------------------- * Tue Dec 20 2005 Ray Strode - 1:2.13.3-2 - rebuild dhcp-11:3.0.3-18 ---------------- * Tue Dec 20 2005 Jason Vas Dias - 11:3.0.3-18 - fix bug 176270: allow routers with an octet of 255 in their IP address dictd-1.9.15-4 -------------- * Tue Dec 20 2005 Karsten Hopp 1.9.15-4 - consult dict.org if no server is specified on the commandline (#176038) docbook-style-dsssl-1.79-4 -------------------------- * Tue Dec 20 2005 Tim Waugh 1.79-4 - Rebuilt again. evolution-webcal-2.4.1-2 ------------------------ * Tue Dec 20 2005 Matthias Clasen 2.4.1-2 - Rebuild against new libedataserver fedora-logos-1.1.37-1 --------------------- * Tue Dec 20 2005 Ray Strode - 1.1.37-1 - another new image from dfong (splash screen) - move screensaver lock dialog background here * Tue Dec 20 2005 Ray Strode - 1.1.36-1 - another new image from dfong (screensaver sprite) fetchmail-6.3.1-1 ----------------- * Tue Dec 20 2005 Miloslav Trmac - 6.3.1-1 - Update to fetchmail-6.3.1 (CVE-2005-4348) gaim-1:1.5.0-9.fc5.2 -------------------- * Tue Dec 20 2005 Ray Strode - rebuilt gedit-1:2.13.0-2 ---------------- * Tue Dec 20 2005 Matthias Clasen - 2.13.0-2 - Update requirements glibc-2.3.90-21 --------------- * Tue Dec 20 2005 Jakub Jelinek 2.3.90-21 - update from CVS - fix pointer (de)mangling in gconv_cache.c * Tue Dec 20 2005 Jakub Jelinek 2.3.90-20 - update from CVS - time ((void *) 1) should segfault, not return -EFAULT (#174856, BZ#1952) - fix errlist generation - update ulps for GCC 4.1 on IA-64 * Mon Dec 19 2005 Jakub Jelinek 2.3.90-19 - update from CVS - sysdeps/generic reorg - setjmp/longjmp jump pointer mangling - rebuilt with GCC 4.1-RH prerelease, worked around broken _Pragma () handling in it - remove glibc-profile subpackage - use non-PLT calls for malloc/free/realloc/memalign invocations in mtrace and mcheck hooks (#175261) - setjmp/longjmp jump pointer mangling on ppc{,64}/ia64/s390{,x} gnbd-kernel-2.6.14.0-20051108.134753.FC5.12.4 --------------------------------------------- * Tue Dec 20 2005 Jesse Keating - rebuilt * Mon May 23 2005 Chris Feist - Fixed depmod in %post scriptlet to use correct kernel. * Tue May 17 2005 Chris Feist - Provides gnbd-kernel-modules & added ARCH=xen to build. gnome-doc-utils-0.5.2-1 ----------------------- * Tue Dec 20 2005 Matthias Clasen - 0.5.2-1 - Update to 0.5.2 gnome-panel-2.13.3-2 -------------------- * Tue Dec 20 2005 Matthias Clasen 2.13.3-2 - Rebuild against new libedataserver gnome-python2-2.12.1-1.2 ------------------------ * Tue Dec 20 2005 Jesse Keating - 2.12.1-1.2 - rebuilt for new libgtop * Fri Dec 09 2005 Jesse Keating - 2.12.1-1.1 - rebuilt * Wed Nov 09 2005 John (J5) Palmieri - 2.12.1-1 - Update to 2.12.1 gnome-python2-extras-2.12.1-8 ----------------------------- * Tue Dec 20 2005 John (J5) Palmieri - 2.12.1-8 - rebuild for new libgtop soname change gnome-screensaver-0.0.23-3 -------------------------- * Tue Dec 20 2005 Ray Strode - 0.0.23-3 - use fedora floater screensaver by default (bug 176229) * Tue Dec 20 2005 Ray Strode - 0.0.23-2 - install the right theme file instead of a tarball * Tue Dec 20 2005 Ray Strode - 0.0.23-1 - Update to 0.0.23 - remove floaters screensaver engine patch (it's upstreamed) - keep fedora branded parts gnome-session-2.12.0-5 ---------------------- * Tue Dec 20 2005 John (J5) Palmieri - 2.12.0-5 - Handle shaped window for splash screen gnome-themes-2.13.2-2 --------------------- * Tue Dec 20 2005 Matthias Clasen - 2.13.2-2 - Update the Clearlooks metacity theme gnome-volume-manager-1.5.7-1 ---------------------------- * Tue Dec 20 2005 Matthias Clasen - 1.5.7-1 - Update to 1.5.7 gnomemeeting-1.2.3-2 -------------------- * Tue Dec 20 2005 Alexander Larsson 1.2.3-2 - Rebuild hdparm-5.9-1 ------------ * Wed Mar 02 2005 Karsten Hopp 5.9-1 - update to 5.9 - build with gcc-4 * Mon Jan 03 2005 Karsten Hopp 5.8-2 - add --help option (#143916) * Fri Nov 26 2004 Karsten Hopp 5.8-1 - update hdparm-6.3-2 ------------ * Tue Dec 20 2005 Karsten Hopp 6.3-2 - use ExcludeArch, this allows building on archs we don't ship such as Alpha (#175919) imake-1.0.0-3 ------------- * Tue Dec 20 2005 Than Ngo 1.0.0-3 - add correct XAppLoadDir #173593 - add more macros for fedora kdeutils-6:3.5.0-2 ------------------ * Tue Dec 20 2005 Than Ngo 6:3.5.0-2 - fix file conflict with superkaramba #176044 kernel-2.6.14-1.1777_FC5 ------------------------ * Tue Dec 20 2005 Dave Jones - Try to disable SMBFS again. smbfs got hardly any fixing in the last 12 months, whilst cifs is under constant improvement. Hopefully things are in better shape than they were last time we tried this back in FC3. * Mon Dec 19 2005 Dave Jones - 2.6.15-rc6 - Various ub stability improvements from Pete Zaitcev. - Update ACPICA. * Mon Dec 19 2005 David Woodhouse - Fix thermal overload on liquid-cooled G5s - Fix USB suspend - Disable floppy driver on ppc32 lftp-3.3.5-2 ------------ * Tue Dec 20 2005 Jason Vas Dias - 3.3.5-2 - fix bug 176175: perl-String-CRC32 now in separate RPM * Thu Dec 15 2005 Jason Vas Dias - 3.3.5-1 - Upgrade to version 3.3.5 - fix bug bz172376 : host lookups should use any address found after timeout * Fri Dec 09 2005 Jesse Keating - rebuilt libcap-1.10-24 -------------- * Mon Dec 19 2005 Karsten Hopp 1.10-24 - added development manpages - as there are no manpages for the executables available, added at least a FAQ (#172324) libselinux-1.29.2-3 ------------------- * Tue Dec 20 2005 Dan Walsh 1.29.2-3 - Fix swig call for getpidcon libtool-1.5.22-1 ---------------- * Tue Dec 20 2005 Karsten Hopp 1.5.22-1 - update to 1.5.22, most prominent fixes are: - Fix 1.5 regression that caused linking a program `-static' to also link statically against installed libtool libraries, contrary to documented (and actual 1.4.x) behavior. - Fix silent failure of `libtoolize --ltdl' if libltdl files not present. nautilus-sendto-0.4-6 --------------------- * Tue Dec 20 2005 Alexander Larsson 0.4-6 - Rebuild openssh-4.2p1-10 ---------------- * Tue Dec 20 2005 Tomas Mraz - 4.2p1-10 - hopefully make the askpass dialog less confusing (#174765) policycoreutils-1.29.2-5 ------------------------ * Tue Dec 20 2005 Dan Walsh 1.29.2-5 - More fixes for chcat * Tue Dec 20 2005 Dan Walsh 1.29.2-4 - Add try catch for files that may not exists * Mon Dec 19 2005 Dan Walsh 1.29.2-3 - Remove commands from genhomedircon for installer sane-backends-1.0.17-1 ---------------------- * Tue Dec 20 2005 Nils Philippsen 1.0.17-1 - version 1.0.17 - reenable gphoto2 backend selinux-policy-2.1.6-13 ----------------------- * Tue Dec 20 2005 Dan Walsh 2.1.6-13 - Add dri libs to textrel_shlib_t - Add system_r role for java - Add unconfined_exec_t for vncserver - Allow slapd to use kerberos system-config-printer-0.6.146-1 ------------------------------- * Tue Dec 20 2005 Tim Waugh 0.6.146-1 - 0.6.146: - Sync languages (bug #176136). tcpdump-14:3.9.4-2 ------------------ * Tue Dec 20 2005 Martin Stransky - 14:3.9.4-2 - fix for #176010 - file owner problem when using 'ring buffer tetex-3.0-12 ------------ * Tue Dec 20 2005 Jindrich Novy 3.0-12 - apply more complete fix for CVE-2005-3193 (#175110) suggested by security response team, taken from xpdf totem-1.3.0-1 ------------- * Tue Dec 20 2005 Matthias Clasen 1.3.0-1 - Update to 1.3.0 xorg-x11-server-1.0.0-1 ----------------------- * Sat Dec 17 2005 Mike A. Harris 1.0.0-1 - Removed xorg-server-0.99.3-rgb.txt-dix-config-fix.patch which is integrated - manNx -> manN - Added libxf86config.a to sdk * Mon Nov 28 2005 Kristian H??gsberg - Add a few missing BuildRequires. Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.2.i686 requires /lib/modules/2.6.14-1.1775_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.2.i686 requires kernel = 0:2.6.14-1.1775_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.2.i686 requires kernel-smp = 0:2.6.14-1.1775_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.2.i686 requires /lib/modules/2.6.14-1.1775_FC5smp cman-kernel - 2.6.14.1-20051219.162641.FC5.3.i686 requires /lib/modules/2.6.14-1.1775_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.3.i686 requires kernel = 0:2.6.14-1.1775_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.3.i686 requires kernel-smp = 0:2.6.14-1.1775_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.3.i686 requires /lib/modules/2.6.14-1.1775_FC5smp dlm-kernel - 2.6.14.1-20051219.162641.FC5.2.i686 requires /lib/modules/2.6.14-1.1775_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.2.i686 requires kernel = 0:2.6.14-1.1775_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.2.i686 requires kernel-smp = 0:2.6.14-1.1775_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.2.i686 requires /lib/modules/2.6.14-1.1775_FC5smp gedit-devel - 1:2.13.0-2.i386 requires gedit = 0:2.13.0 jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 Broken deps for ia64 ---------------------------------------------------------- gedit-devel - 1:2.13.0-2.ia64 requires gedit = 0:2.13.0 jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 gedit-devel - 1:2.13.0-2.ppc requires gedit = 0:2.13.0 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gedit-devel - 1:2.13.0-2.ppc64 requires gedit = 0:2.13.0 gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) Broken deps for s390 ---------------------------------------------------------- gedit-devel - 1:2.13.0-2.s390 requires gedit = 0:2.13.0 jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 systemtap - 0.5.2-2.s390 requires kernel >= 0:2.6.9-11 systemtap - 0.5.2-2.s390 requires kernel-devel Broken deps for s390x ---------------------------------------------------------- gedit-devel - 1:2.13.0-2.s390x requires gedit = 0:2.13.0 jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) libgnome-java - 2.12.0-2.s390x requires libgcj.so.6()(64bit) libgnome-java - 2.12.0-2.s390x requires libcairojava-1.0.so()(64bit) libgtk-java - 2.8.0-7.s390x requires libgcj.so.6()(64bit) libvte-java - 0.11.11-6.3.s390x requires libcairojava-1.0.so()(64bit) systemtap - 0.5.2-2.s390x requires kernel >= 0:2.6.9-11 systemtap - 0.5.2-2.s390x requires kernel-devel Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.2.x86_64 requires /lib/modules/2.6.14-1.1775_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.2.x86_64 requires kernel = 0:2.6.14-1.1775_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.3.x86_64 requires /lib/modules/2.6.14-1.1775_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.3.x86_64 requires kernel = 0:2.6.14-1.1775_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.2.x86_64 requires /lib/modules/2.6.14-1.1775_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.2.x86_64 requires kernel = 0:2.6.14-1.1775_FC5 gedit-devel - 1:2.13.0-2.x86_64 requires gedit = 0:2.13.0 jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) From caolanm at redhat.com Wed Dec 21 08:48:06 2005 From: caolanm at redhat.com (Caolan McNamara) Date: Wed, 21 Dec 2005 08:48:06 +0000 Subject: yum downloads need revamping In-Reply-To: <1135090361.3631.3.camel@c515816-a> References: <1135090361.3631.3.camel@c515816-a> Message-ID: <1135154886.27614.4.camel@localhost.localdomain> On Tue, 2005-12-20 at 08:52 -0600, Otto Haliburton wrote: > i.e. downloading openoffice downloads all language flavors The older 1.1.X openoffice rpms came with an "i18n" package which contained all the languages known to OOo. The 2.0.X language support was split into separate language rpms. If you upgraded from i18n to 2.0.0 the i18n package was Obsoleted by the pile of new langpack rpms. Because there was no way to know which languages from the i18n pack were actually wanted, the only solution was to make all the langpacks obsolete it, that may have led you astray here ? If you installed OOo from scratch and selected only the required langpacks, or upgraded from i18n and then rpm --erased the unwanted langpacks then subsequent yum updates should not (and don't for me) download and install the unnecessary langpacks. C. From ottohaliburton at comcast.net Wed Dec 21 09:45:27 2005 From: ottohaliburton at comcast.net (Otto Haliburton) Date: Wed, 21 Dec 2005 03:45:27 -0600 Subject: yum downloads need revamping In-Reply-To: <1135154886.27614.4.camel@localhost.localdomain> References: <1135090361.3631.3.camel@c515816-a> <1135154886.27614.4.camel@localhost.localdomain> Message-ID: <1135158327.3623.21.camel@c515816-a> On Wed, 2005-12-21 at 08:48 +0000, Caolan McNamara wrote: > On Tue, 2005-12-20 at 08:52 -0600, Otto Haliburton wrote: > > i.e. downloading openoffice downloads all language flavors > > The older 1.1.X openoffice rpms came with an "i18n" package which > contained all the languages known to OOo. The 2.0.X language support was > split into separate language rpms. If you upgraded from i18n to 2.0.0 > the i18n package was Obsoleted by the pile of new langpack rpms. Because > there was no way to know which languages from the i18n pack were > actually wanted, the only solution was to make all the langpacks > obsolete it, that may have led you astray here ? > > If you installed OOo from scratch and selected only the required > langpacks, or upgraded from i18n and then rpm --erased the unwanted > langpacks then subsequent yum updates should not (and don't for me) > download and install the unnecessary langpacks. > > C. > thanks, that is the only explanation for what happened that I've received, and I applied the equivalent to my system, some one else pointed out a command solution to the problem without explanation. But even with the solution, I was looking to getting a discussion going on developing a user interface for yum since up2date has essentially been disabled. Thanks. -- Otto Haliburton From rmo at sunnmore.net Wed Dec 21 10:19:00 2005 From: rmo at sunnmore.net (Roy-Magne Mo) Date: Wed, 21 Dec 2005 11:19:00 +0100 Subject: rawhide report: 20051221 changes In-Reply-To: <200512210821.jBL8LV9F025297@porkchop.devel.redhat.com> References: <200512210821.jBL8LV9F025297@porkchop.devel.redhat.com> Message-ID: <43A92C14.6000903@sunnmore.net> Build System wrote: > gaim-1:1.5.0-9.fc5.2 > -------------------- > * Tue Dec 20 2005 Ray Strode > - rebuilt It does seem like gaim has been rebuilt without SSL-support, I'm unsure what package to file against, it isn't gaim itself since gaim-1.5.0-9.fc5.1 also shows the same behaviour while rebuilding. -- Roy-Magne Mo From sundaram at redhat.com Wed Dec 21 10:21:20 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 21 Dec 2005 15:51:20 +0530 Subject: rawhide report: 20051221 changes In-Reply-To: <43A92C14.6000903@sunnmore.net> References: <200512210821.jBL8LV9F025297@porkchop.devel.redhat.com> <43A92C14.6000903@sunnmore.net> Message-ID: <43A92CA0.7090005@redhat.com> Roy-Magne Mo wrote: > Build System wrote: > >> gaim-1:1.5.0-9.fc5.2 >> -------------------- >> * Tue Dec 20 2005 Ray Strode >> - rebuilt > > > It does seem like gaim has been rebuilt without SSL-support, I'm > unsure what package to file against, it isn't gaim itself since > gaim-1.5.0-9.fc5.1 also shows the same behaviour while rebuilding. You can file it against gaim itself. regards Rahul From clovis at agr.unicamp.br Wed Dec 21 10:21:55 2005 From: clovis at agr.unicamp.br (Clovis Tristao) Date: Wed, 21 Dec 2005 08:21:55 -0200 Subject: Yum Error-HELP In-Reply-To: <1134754862.30209.14.camel@dhollis-lnx.sunera.com> References: <43A2DF86.8070409@agr.unicamp.br> <1134754862.30209.14.camel@dhollis-lnx.sunera.com> Message-ID: <43A92CC3.2040604@agr.unicamp.br> Hi David, David Hollis wrote: > On Fri, 2005-12-16 at 13:38 -0200, Clovis Tristao wrote: > >> Hi, >> >> I've to update my system using yum -y update, but appears this errors: >> >> Error: Missing Dependency: dbus = 0.50-1 is needed by package dbus-qt >> > > dbus-qt is now gone. rpm -e dbus-qt to get rid of it and dbus will be > able to upgrade. > > I've tried remove the dbus-qt but appear this message. Error: Missing Dependency: dbus = 0.50-1 is needed by package dbus-qt Error: Missing Dependency: libdbus-1.so.1 is needed by package dbus-qt [root at hostname clovis]# rpm -e dbus-qt erro: Failed dependencies: libdbus-qt-1.so.1 is needed by (installed) kdebase-3.5.0-0.1.rc2.i386 Clovis -- Clovis Tristao - UNICAMP/Faculdade de Engenharia Agricola Administrador de Redes - Secao de Informatica (SINFO) E-mail: mailto:clovis at agr.unicamp.br http://www.agr.unicamp.br Fone(0xx19) 37881031-37881038 ou FAX(55xx19) 37881005/37881010 -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at redhat.com Wed Dec 21 10:26:38 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 21 Dec 2005 15:56:38 +0530 Subject: Yum Error-HELP In-Reply-To: <43A92CC3.2040604@agr.unicamp.br> References: <43A2DF86.8070409@agr.unicamp.br> <1134754862.30209.14.camel@dhollis-lnx.sunera.com> <43A92CC3.2040604@agr.unicamp.br> Message-ID: <43A92DDE.9010108@redhat.com> Hi > I've tried remove the dbus-qt but appear this message. > Error: Missing Dependency: dbus = 0.50-1 is needed by package dbus-qt > Error: Missing Dependency: libdbus-1.so.1 is needed by package dbus-qt > [root at hostname clovis]# rpm -e dbus-qt > erro: Failed dependencies: > libdbus-qt-1.so.1 is needed by (installed) > kdebase-3.5.0-0.1.rc2.i386 Try yum remove dbus-qt. If you need KDE again yum install kdebase or yum groupinstall "KDE (K Desktop Environment)" -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From rmo at sunnmore.net Wed Dec 21 10:31:55 2005 From: rmo at sunnmore.net (Roy-Magne Mo) Date: Wed, 21 Dec 2005 11:31:55 +0100 Subject: rawhide report: 20051221 changes In-Reply-To: <43A92CA0.7090005@redhat.com> References: <200512210821.jBL8LV9F025297@porkchop.devel.redhat.com> <43A92C14.6000903@sunnmore.net> <43A92CA0.7090005@redhat.com> Message-ID: <43A92F1B.6020908@sunnmore.net> Rahul Sundaram wrote: > Roy-Magne Mo wrote: > >> Build System wrote: >> >>> gaim-1:1.5.0-9.fc5.2 >>> -------------------- >>> * Tue Dec 20 2005 Ray Strode >>> - rebuilt >> >> >> It does seem like gaim has been rebuilt without SSL-support, I'm >> unsure what package to file against, it isn't gaim itself since >> gaim-1.5.0-9.fc5.1 also shows the same behaviour while rebuilding. > > You can file it against gaim itself. Filed as bz #176314 -- Roy-Magne Mo From sundaram at redhat.com Wed Dec 21 10:38:49 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 21 Dec 2005 16:08:49 +0530 Subject: rawhide report: 20051221 changes In-Reply-To: <43A92F1B.6020908@sunnmore.net> References: <200512210821.jBL8LV9F025297@porkchop.devel.redhat.com> <43A92C14.6000903@sunnmore.net> <43A92CA0.7090005@redhat.com> <43A92F1B.6020908@sunnmore.net> Message-ID: <43A930B9.3030909@redhat.com> Roy-Magne Mo wrote: >> >> You can file it against gaim itself. > > > Filed as bz #176314 > Yep. have been watching #fedorabot. Thanks -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From pbrobinson at gmail.com Wed Dec 21 11:07:19 2005 From: pbrobinson at gmail.com (Peter Robinson) Date: Wed, 21 Dec 2005 11:07:19 +0000 Subject: rawhide report: 20051221 changes In-Reply-To: <43A92C14.6000903@sunnmore.net> References: <200512210821.jBL8LV9F025297@porkchop.devel.redhat.com> <43A92C14.6000903@sunnmore.net> Message-ID: <5256d0b0512210307h751070ffn4cdc88a08af57a66@mail.gmail.com> On 12/21/05, Roy-Magne Mo wrote: > Build System wrote: > > > gaim-1:1.5.0-9.fc5.2 > > -------------------- > > * Tue Dec 20 2005 Ray Strode > > - rebuilt > > It does seem like gaim has been rebuilt without SSL-support, I'm unsure > what package to file against, it isn't gaim itself since > gaim-1.5.0-9.fc5.1 also shows the same behaviour while rebuilding. Probably needs updating to nss etc (instead of mozilla-nss) like evolution needed. Pete From walovaton at yahoo.com.mx Wed Dec 21 03:20:06 2005 From: walovaton at yahoo.com.mx (William Lovaton) Date: Tue, 20 Dec 2005 22:20:06 -0500 Subject: Plan for the Holidays In-Reply-To: <1135122188.10390.3.camel@yoda.loki.me> References: <1135122188.10390.3.camel@yoda.loki.me> Message-ID: <1135135206.2146.14.camel@athlon2000> Please, fix the evolution-data-server conflict and I'll be able to install Gnome in my shiny new RawHide box. I need MS Exchange connectivity at work so I will be testing this. I plan to give Apache and PHP a spin too. Merry hacking to all of you! -William El mar, 20-12-2005 a las 15:43 -0800, Jesse Keating escribi??: > With the holidays upcoming, I plan to get the devel tree as broken-dep > free as possible. This includes the foo-kernel packages. I'll be > trying to keep those in sync with the new kernels that are pushed into > rawhide. A lot of folks will have time off over the next couple weeks > and if they choose to test stuff I'd like it to be as easy as possible. > > That said, I think it would be good for developers to post what > specifically they think should be tested during this time. What > components do we need some extra eyes on as we approach test2 freeze? > > Off the top of my head, we need the java stack tested, and that is a > pretty big thing. Also the functionality of your favorite apps is a > good thing to target, given that everything has been rebuilt with the > new gcc. > > So Developers? What would you like the masses to test? > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ?gratis! Reg?strate ya - http://correo.yahoo.com.mx/ From vonbrand at inf.utfsm.cl Tue Dec 20 21:44:15 2005 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Tue, 20 Dec 2005 18:44:15 -0300 Subject: scim-libs not signed error when using yum?? In-Reply-To: Your message of "Tue, 20 Dec 2005 09:45:17 -0800." <200512200945.17534.jkeating@j2solutions.net> Message-ID: <200512202144.jBKLiFA7004311@laptop11.inf.utfsm.cl> Jesse Keating wrote: > On Tuesday 20 December 2005 09:37, Horst von Brand wrote: > > Could The Powers That Be consider signing the packages? Even with a > > rawhide-only key? That way I'd sleep a little better, knowing I've got no > > malicious gunk installed on my machine. > It is test software, we aren't completely sure it isn't malicious gunk from > upstream.... At least I know it is the high-explosive gunk from rawhide... -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From dwmw2 at infradead.org Wed Dec 21 12:28:03 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Wed, 21 Dec 2005 12:28:03 +0000 Subject: Too much time wasted installing fedora on raid1 In-Reply-To: <43A84AC9.5050906@poolshark.org> References: <20051219201653.GU1556@stingr.net> <1135026753.2947.23.camel@laptopd505.fenrus.org> <20051220085657.GW1556@stingr.net> <1135071978.2952.8.camel@laptopd505.fenrus.org> <20051220101303.GB23000@ryoko.camperquake.de> <1135097822.3240.1.camel@localhost.localdomain> <43A84AC9.5050906@poolshark.org> Message-ID: <1135168083.3515.68.camel@pmac.infradead.org> On Tue, 2005-12-20 at 10:17 -0800, Denis Leroy wrote: > Also, the layered approach of RAID is why RAID "just works", trying to > build the redundancy into the filesystem itself would be pure madness. > There are many excellent OS design books that will explain this much > better than i ever could. RAID 'just works' in much the same way that microkernels and the OSI networking model 'work' -- suboptimally. It's a symptom of a popular design methodology which if allowed free rein would make Modula-3? programmers of us all. I'm sure there are many OS design books which Linus could have read that would have explained why microkernels were better, too. Personally, I'm happy that he wasn't persuaded. The next file system I write will probably do this correctly, but it'll be another flash file system, so won't be relevant to block devices. -- dwmw2 ? Or maybe Java, these days. The bondage and discipline principle is much the same. From rodd at clarkson.id.au Wed Dec 21 12:44:33 2005 From: rodd at clarkson.id.au (Rodd Clarkson) Date: Wed, 21 Dec 2005 23:44:33 +1100 Subject: gnome / xorg / nautilus / cairo / freetype desktop rendering slow In-Reply-To: <43A839F0.7070608@web.de> References: <43A7C889.8010904@web.de> <1135069920.3149.4.camel@localhost.localdomain> <43A839F0.7070608@web.de> Message-ID: <1135169073.2902.1.camel@localhost.localdomain> On Tue, 2005-12-20 at 18:05 +0100, Marcus Hartig wrote: > Rodd Clarkson wrote: > > > I'm also unable to get better than 1600x1200 resolution on my 1920x1200 > > screen. > > Have you tried to use a modeline: "gtf 1920 1200 60" > > # 1920x1200 @ 60.00 Hz (GTF) hsync: 74.52 kHz; pclk: 193.16 MHz > Modeline "1920x1200_60.00" 193.16 1920 2048 2256 2592 1200 1201 1204 > 1242 -HSync +Vsync > > But then use "1920x1200_60.00" as resolution from this example. Line > break is here also ath end! > > My xorg nv driver runs here also with the native 1440x900 only with a > modeline in xorg.conf. :-( Marcus, I'm not sure where you're suggesting I put this information (presumably, /etc/X11/xorg.conf, but even then not sure where in the conf). Could you supply the entire file or some more clues on where to put? R. -- "It's a fine line between denial and faith. It's much better on my side" From jfrieben at freesurf.fr Wed Dec 21 13:06:49 2005 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Wed, 21 Dec 2005 14:06:49 +0100 (CET) Subject: rawhide report: 20051221 changes - X server removed Message-ID: <64905.194.94.224.254.1135170409.squirrel@jose.freesurf.fr> Strange things are going on at Red Hat: - consumption of psychedelic substances by Red Hat developers exhibiting through the new bubble style artwork. ;o) - today's updates applied through "pup" -removed- the "xorg-x11-server-Xorg" package - "kernel-devel" and "kernel-doc" got updated but not the "kernel" package itself - kernels 2.6.14-1.1777_FC5 and 2.6.14-1.1777_FC5 do not honour the "single" boot option as previous kernels did. Strange days, indeed ... . From arjan at fenrus.demon.nl Wed Dec 21 13:14:56 2005 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Wed, 21 Dec 2005 14:14:56 +0100 Subject: rawhide report: 20051221 changes - X server removed In-Reply-To: <64905.194.94.224.254.1135170409.squirrel@jose.freesurf.fr> References: <64905.194.94.224.254.1135170409.squirrel@jose.freesurf.fr> Message-ID: <1135170896.3456.27.camel@laptopd505.fenrus.org> On Wed, 2005-12-21 at 14:06 +0100, Joachim Frieben wrote: > - kernels 2.6.14-1.1777_FC5 and 2.6.14-1.1777_FC5 do not honour > the "single" boot option as previous kernels did. single is not a kernel option rather an initscripts thing.. From laroche at redhat.com Wed Dec 21 13:19:46 2005 From: laroche at redhat.com (Florian La Roche) Date: Wed, 21 Dec 2005 14:19:46 +0100 Subject: rawhide report: 20051221 changes - X server removed In-Reply-To: <1135170896.3456.27.camel@laptopd505.fenrus.org> References: <64905.194.94.224.254.1135170409.squirrel@jose.freesurf.fr> <1135170896.3456.27.camel@laptopd505.fenrus.org> Message-ID: <20051221131946.GA5479@dudweiler.stuttgart.redhat.com> On Wed, Dec 21, 2005 at 02:14:56PM +0100, Arjan van de Ven wrote: > On Wed, 2005-12-21 at 14:06 +0100, Joachim Frieben wrote: > > > - kernels 2.6.14-1.1777_FC5 and 2.6.14-1.1777_FC5 do not honour > > the "single" boot option as previous kernels did. > > single is not a kernel option rather an initscripts thing.. But the kernel hands over unknown options then to init, so this should still work ok? SysVinit did also change, so you should probably check that for changes first. regards, Florian La Roche From jspaleta at gmail.com Wed Dec 21 13:23:36 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 21 Dec 2005 08:23:36 -0500 Subject: rawhide report: 20051221 changes - X server removed In-Reply-To: <64905.194.94.224.254.1135170409.squirrel@jose.freesurf.fr> References: <64905.194.94.224.254.1135170409.squirrel@jose.freesurf.fr> Message-ID: <604aa7910512210523t7ad40ca9m253fdd1cff47bd32@mail.gmail.com> On 12/21/05, Joachim Frieben wrote: > - today's updates applied through "pup" -removed- the > "xorg-x11-server-Xorg" package > > - "kernel-devel" and "kernel-doc" got updated but not the "kernel" > package itself is this a 64bit system or a 32 bit system? Is your pup session logged in yum.log? I can not reproduce either of these issues. -jef From tmus at tmus.dk Wed Dec 21 13:25:02 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Wed, 21 Dec 2005 14:25:02 +0100 Subject: rawhide report: 20051221 changes - X server removed In-Reply-To: <1135170896.3456.27.camel@laptopd505.fenrus.org> References: <64905.194.94.224.254.1135170409.squirrel@jose.freesurf.fr> <1135170896.3456.27.camel@laptopd505.fenrus.org> Message-ID: Arjan van de Ven wrote: > On Wed, 2005-12-21 at 14:06 +0100, Joachim Frieben wrote: > >> - kernels 2.6.14-1.1777_FC5 and 2.6.14-1.1777_FC5 do not honour >> the "single" boot option as previous kernels did. > > single is not a kernel option rather an initscripts thing.. > Interestingly, SysVinit got updated. This could be the source of your troubles (didn't look - only noticed), but do try s or even S instead of single and see if that changes anything. good luck :) /Thomas From m.f.h at web.de Wed Dec 21 13:42:35 2005 From: m.f.h at web.de (Marcus Hartig) Date: Wed, 21 Dec 2005 14:42:35 +0100 Subject: gnome / xorg / nautilus / cairo / freetype desktop rendering slow In-Reply-To: <1135169073.2902.1.camel@localhost.localdomain> References: <43A7C889.8010904@web.de> <1135069920.3149.4.camel@localhost.localdomain> <43A839F0.7070608@web.de> <1135169073.2902.1.camel@localhost.localdomain> Message-ID: <43A95BCB.50405@web.de> Rodd Clarkson wrote: > Could you supply the entire file or some more clues on where to put? from my /etc/X11/xorg.conf: [...] Section "Monitor" Identifier "Monitor0" VendorName "DELL" ModelName "Inspiron 9300 LCD 1440x900" HorizSync 31.5 - 85.0 VertRefresh 59.0 - 75.0 ... # 1440x900 @ 60.00 Hz (GTF) hsync: 55.92 kHz; pclk: 106.47 MHz Modeline "1440x900_60.00" 106.47 1440 1520 1672 1904 900 901 904 932 -HSync +Vsync Option "dpms" "on" EndSection ... Section "Screen" Identifier "Screen0" Device "Videocard0" Monitor "Monitor0" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 16 Modes "1440x900_60.00" "1280x720_60.00" 1024x768_60.00" "800x600_60.00" "720x576_60.00" EndSubSection SubSection "Display" Viewport 0 0 Depth 24 Modes "1440x900_60.00" "1280x720_60.00" "1024x768_60.00" "800x600_60.00" "720x576_60.00" EndSubSection EndSection If you use other modes for gaming or whatever, put the needed modelines (generated from gtf) in the monitor section or in an extra "Modes" section, if more monitors are connected. http://www.linux-laptop.net/ Marcus From mailinglists at erwinrol.com Wed Dec 21 13:43:50 2005 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 21 Dec 2005 14:43:50 +0100 Subject: Radeon driver hang Message-ID: <1135172630.3105.2.camel@xpc.home.erwinrol.com> Hey all, I added Benjamin's patch to the ati driver SRPM to test if it works, and for me it seems to work, my machine doesn't hard hang anymore. If you want to try it out the SRPM can be found here; http://www.erwinrol.com/downloads/software/xorg-x11-drv-ati-6.5.7-2.src.rpm - Erwin From mailinglists at erwinrol.com Wed Dec 21 13:45:19 2005 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 21 Dec 2005 14:45:19 +0100 Subject: boot problems Message-ID: <1135172719.3105.4.camel@xpc.home.erwinrol.com> The last two kernels do not want to boot, is anybody else having problems with booting ? the last working kernel is 2.6.14-1.1773_FC5 - Erwin From mailinglists at erwinrol.com Wed Dec 21 13:48:42 2005 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 21 Dec 2005 14:48:42 +0100 Subject: gnome-terminal weirdness Message-ID: <1135172922.3105.9.camel@xpc.home.erwinrol.com> hey all, I noticed a weird problem with gnome-terminal, my session has one terminal open so when i login there is one working terminal. When i now open a new default terminal from the terminal-window menu there will be a new working terminal. When i open a new terminal from the "Applications" menu there will be a new terminal window but all terminal windows freeze and will not work anymore (also no window updates). Opening a xterm still works fine. Is anybody else seeing this problem ? - Erwin From jfrieben at freesurf.fr Wed Dec 21 13:49:44 2005 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Wed, 21 Dec 2005 14:49:44 +0100 (CET) Subject: rawhide report: 20051221 changes - X server removed In-Reply-To: <604aa7910512210523t7ad40ca9m253fdd1cff47bd32@mail.gmail.com> References: <604aa7910512210523t7ad40ca9m253fdd1cff47bd32@mail.gmail.com> Message-ID: <11454.194.94.224.254.1135172984.squirrel@arlette.freesurf.fr> No, my "pup" sessions do not get logged. Since yesterday, I have been using "pup". The log file ends on Dec 19. The computer is an IBM ThinkPad T23, thus a 32 bit system. Since "up2date" stopped working completely, I used to call "yum" directly from the command line most of the time. Btw, the three kernel RPMs are still in "/var/cache/yum/development/ packages". I thus installed the missing kernel RPM simply via "rpm" from there. -Joachim > On 12/21/05, Joachim Frieben wrote: >> - today's updates applied through "pup" -removed- the >> "xorg-x11-server-Xorg" package >> >> - "kernel-devel" and "kernel-doc" got updated but not the "kernel" >> package itself > > is this a 64bit system or a 32 bit system? > Is your pup session logged in yum.log? > > I can not reproduce either of these issues. > > -jef > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From tmus at tmus.dk Wed Dec 21 13:44:07 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Wed, 21 Dec 2005 14:44:07 +0100 Subject: rawhide report: 20051221 changes - X server removed In-Reply-To: <64905.194.94.224.254.1135170409.squirrel@jose.freesurf.fr> References: <64905.194.94.224.254.1135170409.squirrel@jose.freesurf.fr> Message-ID: Joachim Frieben wrote: > Strange things are going on at Red Hat: > > - consumption of psychedelic substances by Red Hat developers > exhibiting through the new bubble style artwork. ;o) > > - today's updates applied through "pup" -removed- the > "xorg-x11-server-Xorg" package > > - "kernel-devel" and "kernel-doc" got updated but not the "kernel" > package itself > > - kernels 2.6.14-1.1777_FC5 and 2.6.14-1.1777_FC5 do not honour > the "single" boot option as previous kernels did. > > Strange days, indeed ... . > > I did just try with 1 as a kernel command line option and notices something rather strange. init acknowledges the 1 flags and says INIT: going to single user mode (or something to that end) the on the next line it continues INIT: booting to runlevel 5 (again not exact string, but something similar) I'm guessing the new init has some sort of problem? Or /etc/rc.d/rc is perhaps not handling something properly? I can't seem to recall exactly where, what is supposed to happen. /Thomas From clydekunkel7734 at cox.net Wed Dec 21 14:09:05 2005 From: clydekunkel7734 at cox.net (Clyde E. Kunkel) Date: Wed, 21 Dec 2005 09:09:05 -0500 Subject: boot problems In-Reply-To: <1135172719.3105.4.camel@xpc.home.erwinrol.com> References: <1135172719.3105.4.camel@xpc.home.erwinrol.com> Message-ID: <43A96201.2020500@cox.net> Erwin Rol wrote: > The last two kernels do not want to boot, is anybody else having > problems with booting ? > > the last working kernel is 2.6.14-1.1773_FC5 > > - Erwin > > try acpi=off. worked for me with kernel 1776 -- Regards, Old Fart From clydekunkel7734 at cox.net Wed Dec 21 14:10:37 2005 From: clydekunkel7734 at cox.net (Clyde E. Kunkel) Date: Wed, 21 Dec 2005 09:10:37 -0500 Subject: gnome-terminal weirdness In-Reply-To: <1135172922.3105.9.camel@xpc.home.erwinrol.com> References: <1135172922.3105.9.camel@xpc.home.erwinrol.com> Message-ID: <43A9625D.6090709@cox.net> Erwin Rol wrote: > hey all, > > I noticed a weird problem with gnome-terminal, my session has one > terminal open so when i login there is one working terminal. When i now > open a new default terminal from the terminal-window menu there will be > a new working terminal. When i open a new terminal from the > "Applications" menu there will be a new terminal window but all terminal > windows freeze and will not work anymore (also no window updates). > Opening a xterm still works fine. > > Is anybody else seeing this problem ? > > - Erwin > > see bug 176029 -- Regards, Old Fart From al at authentidate.de Wed Dec 21 14:12:46 2005 From: al at authentidate.de (Andreas Laumann) Date: Wed, 21 Dec 2005 15:12:46 +0100 Subject: boot problems In-Reply-To: <1135172719.3105.4.camel@xpc.home.erwinrol.com> References: <1135172719.3105.4.camel@xpc.home.erwinrol.com> Message-ID: <1135174366.5235.9.camel@justine.inexnet.de> Am Mittwoch, den 21.12.2005, 14:45 +0100 schrieb Erwin Rol: > The last two kernels do not want to boot, is anybody else having > problems with booting ? > > the last working kernel is 2.6.14-1.1773_FC5 Same behaviour here. During boot up it says the eth0 dev ( RTL-8139/8139C/8139C+ (rev 10)) is already in use and can't use. after this message the system hangs. Maybe there is a fight between 8139too and 8139cp ??? Booting w/ 2.6.14-1.1773_FC5 works This is a fully updated rawhide system. > - Erwin > > -- The Theory of Escalating Commitment: "The cost of continuing mistakes is borne by others, while the cost of admitting mistakes is borne by yourself." -- Joseph Stiglitz, Nobel Laureate in Economics Andreas Laumann phone: +49 211 43 69 89-61 Chief Software Architect mobile: +49 151 167 227 51 Authentidate International AG fax: +49 211 43 69 89-19 Grossenbaumer Weg 6 mail: al at authentidate.de 40472 Duesseldorf / Germany web: http://www.authentidate.de From mailinglists at erwinrol.com Wed Dec 21 14:13:54 2005 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 21 Dec 2005 15:13:54 +0100 Subject: boot problems In-Reply-To: <43A96201.2020500@cox.net> References: <1135172719.3105.4.camel@xpc.home.erwinrol.com> <43A96201.2020500@cox.net> Message-ID: <1135174434.3105.11.camel@xpc.home.erwinrol.com> On Wed, 2005-12-21 at 09:09 -0500, Clyde E. Kunkel wrote: > Erwin Rol wrote: > > The last two kernels do not want to boot, is anybody else having > > problems with booting ? > > > > the last working kernel is 2.6.14-1.1773_FC5 > try acpi=off. worked for me with kernel 1776 With other words, you have problems too :-) - Erwin From ellson at research.att.com Wed Dec 21 14:17:13 2005 From: ellson at research.att.com (John Ellson) Date: Wed, 21 Dec 2005 09:17:13 -0500 Subject: boot problems In-Reply-To: <43A96201.2020500@cox.net> References: <1135172719.3105.4.camel@xpc.home.erwinrol.com> <43A96201.2020500@cox.net> Message-ID: <43A963E9.9020900@research.att.com> Clyde E. Kunkel wrote: > Erwin Rol wrote: >> The last two kernels do not want to boot, is anybody else having >> problems with booting ? >> >> the last working kernel is 2.6.14-1.1773_FC5 >> >> - Erwin >> >> > try acpi=off. worked for me with kernel 1776 > Just "acpi=off" fixed my i686smp box, but for my x86_64 I needed "acpi=off irqpoll" with kernel 1777 otherwise my eth0 didn't start. From nicolas.mailhot at laposte.net Wed Dec 21 14:25:41 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Wed, 21 Dec 2005 15:25:41 +0100 (CET) Subject: scim-libs not signed error when using yum?? In-Reply-To: <200512202144.jBKLiFA7004311@laptop11.inf.utfsm.cl> References: Your message of "Tue, 20 Dec 2005 09:45:17 -0800." <200512200945.17534.jkeating@j2solutions.net> <200512202144.jBKLiFA7004311@laptop11.inf.utfsm.cl> Message-ID: <36354.192.54.193.35.1135175141.squirrel@rousalka.dyndns.org> On Mar 20 d?cembre 2005 22:44, Horst von Brand wrote: > Jesse Keating wrote: >> On Tuesday 20 December 2005 09:37, Horst von Brand wrote: >> > Could The Powers That Be consider signing the packages? Even with a >> > rawhide-only key? That way I'd sleep a little better, knowing I've got >> no >> > malicious gunk installed on my machine. > >> It is test software, we aren't completely sure it isn't malicious gunk >> from >> upstream.... > > At least I know it is the high-explosive gunk from rawhide... +1 There's a difference between raw packages (devel) and malicious packages. -- Nicolas Mailhot From jfrieben at freesurf.fr Wed Dec 21 14:26:54 2005 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Wed, 21 Dec 2005 15:26:54 +0100 (CET) Subject: rawhide report: 20051221 changes - X server removed Message-ID: <22603.194.94.224.254.1135175214.squirrel@arlette.freesurf.fr> Tried booting with "linux 1 ro root=/dev/VolGroup00/LogVol0", same result. -Joachim > On Wed, 2005-12-21 at 14:06 +0100, Joachim Frieben wrote: > >> - kernels 2.6.14-1.1777_FC5 and 2.6.14-1.1777_FC5 do not honour >> the "single" boot option as previous kernels did. > > single is not a kernel option rather an initscripts thing.. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From ph18 at cornell.edu Wed Dec 21 14:42:01 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Wed, 21 Dec 2005 09:42:01 -0500 Subject: Everything installs In-Reply-To: <1135115950.3623.6.camel@c515816-a> References: <1135090361.3631.3.camel@c515816-a> <604aa7910512200706u1fcc7fdasfa8465172c235624@mail.gmail.com> <1135092644.3631.12.camel@c515816-a> <604aa7910512200748w6a00b7f6n4fc7a1c20363a93e@mail.gmail.com> <1135102281.3445.17.camel@mentorng.gurulabs.com> <1135115950.3623.6.camel@c515816-a> Message-ID: <43A969B9.4060200@cornell.edu> Otto Haliburton wrote: > the possible solution is noted. I am going to toss this out and I know > that it has been suggested many times, and that is that a graphical > interface be created for yum. This has both a good and a bad component, > which could be solved by having a standalone yum and a graphical > interface to the stand along version. Up2date seems to function as one > but I believe it has been effectively disabled in fc4. This is a > suggestion but maybe a development thing for the future. > There are interesting challenges here... I recently got Linux running on a Sun Ultra 10, and I chose Debian because it's one of the few distributions that will easily install on SPARC. I tried a more-or-less everything install first and found out that X would crash the machine. I didn't really need X on that machine, so I wanted to do an install that had basic development tools (gcc, awk, perl, time, ...) but no X. I was impressed with apt-get, but the text UI for configuring packages in Debian is atrocious. It didn't help that I was using a funky Sun keyboard with the control key in the wrong place, but I found keystroke combinations to be completely unintuitive -- I ended off ticking off a large number of development packages, and sure enough, some of them depended on xlibs, so the dependency resolver added some X windows related packages to the list, and I wasn't so sure if it was trying to install X libraries (which would have been fine) or an X server (which would have turned the machine into a boat anchor.) Debian diehards will probably say that it's not so bad if you are experienced in Debian, but that's the whole point -- if deb-pkg-config confuses somebody with a decade+ of experience in Linux and Unix, what is it like for a real novice? I pine for the days of Slackware, where it was easy to select bundles, or drill down into the bundles, pick out individual packages, get good descriptions of the packages, and easily decide what you want. I end up doing an everything install in Fedora and RHEL when I build new machines because I know there are things I like in the everything install that won't come up in other installs. Because I don't have a good synoptic view of the packages, I can't tell you what they are! Like a lot of people, I'd badly like to have an "english-only" install... I ~would~ like Unicode fonts, I need uxterm and I need Mozilla to render CJK text out of the box (big advantage that Fedora/RHEL has over Linux)... Not because I can understand CJK text, but because I sometimes need to tell what language a site is and sometimes need to make sure that my software isn't double-encoding something. I ~don't~ need 1 GB of language packs. I wish I could do an "everything but Open Office" install. I just don't have any use for it -- and I really don't have any use for clicking on something that's got nothing to do with any kind of Office and then having my machine grind for two minutes to pop up an Open Office window full of garbage. It's not just a matter of bitching about Fedora/RHEL: managing the software you've got is a nightmare on any platform today. The other day I installed the "Yahoo Widget Engine" on my Windows machine, and it never worked... But now it takes ten seconds longer for it to boot and it pops up dialog boxes asking me if I want to upgrade it. I'm happy that people are talking about these issues... Applications like Azureus and Mozilla, for better and for worse, are bringing some problems from Windows to the Unix world, and it would be good to see a solution. From sundaram at redhat.com Wed Dec 21 14:47:01 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 21 Dec 2005 20:17:01 +0530 Subject: Everything installs In-Reply-To: <43A969B9.4060200@cornell.edu> References: <1135090361.3631.3.camel@c515816-a> <604aa7910512200706u1fcc7fdasfa8465172c235624@mail.gmail.com> <1135092644.3631.12.camel@c515816-a> <604aa7910512200748w6a00b7f6n4fc7a1c20363a93e@mail.gmail.com> <1135102281.3445.17.camel@mentorng.gurulabs.com> <1135115950.3623.6.camel@c515816-a> <43A969B9.4060200@cornell.edu> Message-ID: <43A96AE5.5070308@redhat.com> Paul A Houle wrote: > Otto Haliburton wrote: > >> the possible solution is noted. I am going to toss this out and I know >> that it has been suggested many times, and that is that a graphical >> interface be created for yum. > System-config-packages is getting a yum backend. Pup in the current development tree will perform software updates based on yum. There is yumex in Fedora Extras already. >> >> > > There are interesting challenges here... > > I recently got Linux running on a Sun Ultra 10, and I chose Debian > because it's one of the few distributions that will easily install on > SPARC. If you want a Fedora based system on SPARC, try http://auroralinux.org/ -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From pjones at redhat.com Wed Dec 21 15:45:21 2005 From: pjones at redhat.com (Peter Jones) Date: Wed, 21 Dec 2005 10:45:21 -0500 Subject: kernel-2.6.14-1.1653_FC4.netdev.6? In-Reply-To: <20051220195556.GB7693@redhat.com> References: <43A05044.7060803@cygnusx-1.org> <20051215005152.GF26108@rathann.pekin.waw.pl> <20051215010803.GE9801@redhat.com> <20051215162712.GC16712@redhat.com> <20051215215952.GC4336@rathann.pekin.waw.pl> <20051216131221.GA9708@redhat.com> <20051216225617.GC4376@rathann.pekin.waw.pl> <20051219224322.GA5815@rathann.pekin.waw.pl> <1135098078.3240.3.camel@localhost.localdomain> <20051220195556.GB7693@redhat.com> Message-ID: <1135179922.3240.15.camel@localhost.localdomain> On Tue, 2005-12-20 at 14:55 -0500, John W. Linville wrote: > On Tue, Dec 20, 2005 at 12:01:17PM -0500, Peter Jones wrote: > > On Mon, 2005-12-19 at 23:43 +0100, Dominik 'Rathann' Mierzejewski wrote: > > > > > Additionally, I can't turn on debugging. modprobe ipw2200 debug=0xffff > > > output is no more verbose than without the debug option. > > > > With which kernel? I turned CONFIG_IPW_DEBUG back on several days > > ago... > > The corresponding CONFIG_IPW2100_DEBUG and CONFIG_IPW2200_DEBUG are > probably off in the netdev.6 kernel, iirc. They're probably worth turning back on there, as well. They don't change any behavior unless you use the debug= option or modify /sys/bus/pci/drivers/ipw*/debug_level , and it's basically impossible to figure out if something is going wrong in the driver without doing so. (and the driver is still relatively young, so often that kind of diagnosis is needed) -- Peter From tmus at tmus.dk Wed Dec 21 15:49:35 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Wed, 21 Dec 2005 16:49:35 +0100 Subject: rawhide report: 20051221 changes - X server removed In-Reply-To: <64905.194.94.224.254.1135170409.squirrel@jose.freesurf.fr> References: <64905.194.94.224.254.1135170409.squirrel@jose.freesurf.fr> Message-ID: Joachim Frieben wrote: > Strange things are going on at Red Hat: > > - consumption of psychedelic substances by Red Hat developers > exhibiting through the new bubble style artwork. ;o) > > - today's updates applied through "pup" -removed- the > "xorg-x11-server-Xorg" package > > - "kernel-devel" and "kernel-doc" got updated but not the "kernel" > package itself > > - kernels 2.6.14-1.1777_FC5 and 2.6.14-1.1777_FC5 do not honour > the "single" boot option as previous kernels did. > > Strange days, indeed ... . > > In an attempt to verify my initial thoughts, i installed a SysVinit based on 2.85 (the FC4 version to be exact). After that - booting with an s on the kernel command line puts me into single user mode just fine. /Thomas From sundaram at redhat.com Wed Dec 21 15:57:28 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 21 Dec 2005 21:27:28 +0530 Subject: rawhide report: 20051221 changes - X server removed In-Reply-To: References: <64905.194.94.224.254.1135170409.squirrel@jose.freesurf.fr> Message-ID: <43A97B68.10004@redhat.com> Hi > In an attempt to verify my initial thoughts, i installed a SysVinit > based on 2.85 (the FC4 version to be exact). > > After that - booting with an s on the kernel command line puts me into > single user mode just fine. Kindly file a bug report then. -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From clydekunkel7734 at cox.net Wed Dec 21 16:12:54 2005 From: clydekunkel7734 at cox.net (Clyde E. Kunkel) Date: Wed, 21 Dec 2005 11:12:54 -0500 Subject: rawhide report: 20051221 changes - X server removed In-Reply-To: References: <64905.194.94.224.254.1135170409.squirrel@jose.freesurf.fr> Message-ID: <43A97F06.7000809@cox.net> Thomas M Steenholdt wrote: > Joachim Frieben wrote: >> Strange things are going on at Red Hat: >> >> - consumption of psychedelic substances by Red Hat developers >> exhibiting through the new bubble style artwork. ;o) >> >> - today's updates applied through "pup" -removed- the >> "xorg-x11-server-Xorg" package >> >> - "kernel-devel" and "kernel-doc" got updated but not the "kernel" >> package itself >> >> - kernels 2.6.14-1.1777_FC5 and 2.6.14-1.1777_FC5 do not honour >> the "single" boot option as previous kernels did. >> >> Strange days, indeed ... . >> >> > > In an attempt to verify my initial thoughts, i installed a SysVinit > based on 2.85 (the FC4 version to be exact). > > After that - booting with an s on the kernel command line puts me into > single user mode just fine. > > /Thomas > FWIW, I noticed that during the yum update of SysVinit the following occurred: telinit: timeout opening/writing control channel /dev/initctl -- Regards, Old Fart (my reply to address may be "munged") From katzj at redhat.com Wed Dec 21 16:29:27 2005 From: katzj at redhat.com (Jeremy Katz) Date: Wed, 21 Dec 2005 11:29:27 -0500 Subject: rawhide report: 20051221 changes - X server removed In-Reply-To: <64905.194.94.224.254.1135170409.squirrel@jose.freesurf.fr> References: <64905.194.94.224.254.1135170409.squirrel@jose.freesurf.fr> Message-ID: <1135182568.3033.4.camel@bree.local.net> On Wed, 2005-12-21 at 14:06 +0100, Joachim Frieben wrote: > - today's updates applied through "pup" -removed- the > "xorg-x11-server-Xorg" package Hrmm, I wonder if this is a manifestation of what a couple of other people saw where the package ordering is going wrong. Unfortunately, I've been unable to reproduce this on any of my machines. If anyone can get to a reproducible case, that would be extremely helpful in figuring out what's going wrong. Jeremy From pjones at redhat.com Wed Dec 21 17:01:37 2005 From: pjones at redhat.com (Peter Jones) Date: Wed, 21 Dec 2005 12:01:37 -0500 Subject: rawhide report: 20051221 changes - X server removed In-Reply-To: <20051221131946.GA5479@dudweiler.stuttgart.redhat.com> References: <64905.194.94.224.254.1135170409.squirrel@jose.freesurf.fr> <1135170896.3456.27.camel@laptopd505.fenrus.org> <20051221131946.GA5479@dudweiler.stuttgart.redhat.com> Message-ID: <1135184497.3240.44.camel@localhost.localdomain> On Wed, 2005-12-21 at 14:19 +0100, Florian La Roche wrote: > On Wed, Dec 21, 2005 at 02:14:56PM +0100, Arjan van de Ven wrote: > > On Wed, 2005-12-21 at 14:06 +0100, Joachim Frieben wrote: > > > > > - kernels 2.6.14-1.1777_FC5 and 2.6.14-1.1777_FC5 do not honour > > > the "single" boot option as previous kernels did. > > > > single is not a kernel option rather an initscripts thing.. > > But the kernel hands over unknown options then to init, so this > should still work ok? The kernel doesn't run init; initrd does. But it only passes arguments to it which it finds after an "init=" option. I'm not actually sure where init gets its runlevel from currently -- I suspect rc.sysinit or /etc/rc.d/rc reads /proc/cmdline to figure it out? Bill knows this part of bootup better... -- Peter From notting at redhat.com Wed Dec 21 17:02:59 2005 From: notting at redhat.com (Bill Nottingham) Date: Wed, 21 Dec 2005 12:02:59 -0500 Subject: rawhide report: 20051221 changes - X server removed In-Reply-To: <1135184497.3240.44.camel@localhost.localdomain> References: <64905.194.94.224.254.1135170409.squirrel@jose.freesurf.fr> <1135170896.3456.27.camel@laptopd505.fenrus.org> <20051221131946.GA5479@dudweiler.stuttgart.redhat.com> <1135184497.3240.44.camel@localhost.localdomain> Message-ID: <20051221170258.GA598@devserv.devel.redhat.com> Peter Jones (pjones at redhat.com) said: > The kernel doesn't run init; initrd does. But it only passes arguments > to it which it finds after an "init=" option. I'm not actually sure > where init gets its runlevel from currently -- I suspect rc.sysinit > or /etc/rc.d/rc reads /proc/cmdline to figure it out? > > Bill knows this part of bootup better... The proverbial 'something' broke in init. Looking... Bill From tmus at tmus.dk Wed Dec 21 17:18:06 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Wed, 21 Dec 2005 18:18:06 +0100 Subject: rawhide report: 20051221 changes - X server removed In-Reply-To: <43A97B68.10004@redhat.com> References: <64905.194.94.224.254.1135170409.squirrel@jose.freesurf.fr> <43A97B68.10004@redhat.com> Message-ID: Rahul Sundaram wrote: > Hi > >> In an attempt to verify my initial thoughts, i installed a SysVinit >> based on 2.85 (the FC4 version to be exact). >> >> After that - booting with an s on the kernel command line puts me into >> single user mode just fine. > > Kindly file a bug report then. > Bug filed - #176348, for anyone interested or with something to add. /Thomas From drepper at redhat.com Wed Dec 21 17:27:03 2005 From: drepper at redhat.com (Ulrich Drepper) Date: Wed, 21 Dec 2005 09:27:03 -0800 Subject: Using ns_parseerr() on Fedora Devel In-Reply-To: <20051219155731.GF31712@ryoko.camperquake.de> References: <20051219084905.GA31712@ryoko.camperquake.de> <43A6D0A2.2080901@redhat.com> <20051219155731.GF31712@ryoko.camperquake.de> Message-ID: <43A99067.9090406@redhat.com> Ralf Ertzinger wrote: > But ns_parserr is not private. It is defined if you include . The header content is irrelevant when it comes to deciding what is private or not. > Any suggestions as what the official replacement for ns_parserr is? Write it on your own? Lift it from BIND? -- ? Ulrich Drepper ? Red Hat, Inc. ? 444 Castro St ? Mountain View, CA ? From jkeating at redhat.com Wed Dec 21 17:31:33 2005 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Dec 2005 09:31:33 -0800 Subject: Plan for the Holidays In-Reply-To: <1135135206.2146.14.camel@athlon2000> References: <1135122188.10390.3.camel@yoda.loki.me> <1135135206.2146.14.camel@athlon2000> Message-ID: <1135186293.10390.35.camel@yoda.loki.me> On Tue, 2005-12-20 at 22:20 -0500, William Lovaton wrote: > Please, fix the evolution-data-server conflict and I'll be able to > install Gnome in my shiny new RawHide box. > > I need MS Exchange connectivity at work so I will be testing this. > > I plan to give Apache and PHP a spin too. > > Merry hacking to all of you! > This was fixed in last night's rawhide. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mharris at mharris.ca Wed Dec 21 17:30:18 2005 From: mharris at mharris.ca (Mike A. Harris) Date: Wed, 21 Dec 2005 12:30:18 -0500 Subject: rawhide report: 20051221 changes - X server removed In-Reply-To: <64905.194.94.224.254.1135170409.squirrel@jose.freesurf.fr> References: <64905.194.94.224.254.1135170409.squirrel@jose.freesurf.fr> Message-ID: <43A9912A.6010807@mharris.ca> Joachim Frieben wrote: > - today's updates applied through "pup" -removed- the > "xorg-x11-server-Xorg" package Yeah, after much debate, we decided to move X into Fedora Extras instead of keeping it in core. However, everyone is going on holidays for 2 weeks, so it wont show up in Extras probably until mid January or so. As an interim workaround, the Linux console can be pretty handy at times though. -- Mike A. Harris, Open Source Advocate * http://mharris.ca Proud to be Canadian. From mharris at mharris.ca Wed Dec 21 17:35:21 2005 From: mharris at mharris.ca (Mike A. Harris) Date: Wed, 21 Dec 2005 12:35:21 -0500 Subject: Radeon driver hang In-Reply-To: <1135172630.3105.2.camel@xpc.home.erwinrol.com> References: <1135172630.3105.2.camel@xpc.home.erwinrol.com> Message-ID: <43A99259.30305@mharris.ca> Erwin Rol wrote: > Hey all, > > I added Benjamin's patch to the ati driver SRPM to test if it works, and > for me it seems to work, my machine doesn't hard hang anymore. > > If you want to try it out the SRPM can be found here; > http://www.erwinrol.com/downloads/software/xorg-x11-drv-ati-6.5.7-2.src.rpm As a good general guideline, if you make a custom version of a package that Red Hat ships, and bump the release number, it is a very good idea to also namespace it specially to not conflict with future official Red Hat package version/releases. It also helps to make it more clear that it is not an official Red Hat build when looking at the output of rpm -q et al. What I do for personal custom builds of packages, is namespace them with ".mharris.n" ie: xorg-x11-drv-ati-6.5.7-1.mharris.1.src.rpm Let's me know this was based on the official Red Hat -1 package, and it is my first custom build. If I need to rebuild, it would become .2 on the end, etc. Just thought I'd suggest that, as it's a generally good idea. ;) I wouldn't worry about it for this one now tho, as a new Radeon driver version is about to hit rawhide. -- Mike A. Harris, Open Source Advocate * http://mharris.ca Proud to be Canadian. From notting at redhat.com Wed Dec 21 17:45:54 2005 From: notting at redhat.com (Bill Nottingham) Date: Wed, 21 Dec 2005 12:45:54 -0500 Subject: rawhide report: 20051221 changes - X server removed In-Reply-To: References: <64905.194.94.224.254.1135170409.squirrel@jose.freesurf.fr> <43A97B68.10004@redhat.com> Message-ID: <20051221174554.GA9334@devserv.devel.redhat.com> Thomas M Steenholdt (tmus at tmus.dk) said: > Rahul Sundaram wrote: > >Hi > > > >>In an attempt to verify my initial thoughts, i installed a SysVinit > >>based on 2.85 (the FC4 version to be exact). > >> > >>After that - booting with an s on the kernel command line puts me into > >>single user mode just fine. > > > >Kindly file a bug report then. > > > > Bug filed - #176348, for anyone interested or with something to add. Fixed in -2, it was a bug in upstream 2.86 we pulled in. Bill From tmus at tmus.dk Wed Dec 21 17:38:59 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Wed, 21 Dec 2005 18:38:59 +0100 Subject: rawhide report: 20051221 changes - X server removed In-Reply-To: References: <64905.194.94.224.254.1135170409.squirrel@jose.freesurf.fr> <43A97B68.10004@redhat.com> Message-ID: Thomas M Steenholdt wrote: > Rahul Sundaram wrote: >> Hi >> >>> In an attempt to verify my initial thoughts, i installed a SysVinit >>> based on 2.85 (the FC4 version to be exact). >>> >>> After that - booting with an s on the kernel command line puts me >>> into single user mode just fine. >> >> Kindly file a bug report then. >> > > Bug filed - #176348, for anyone interested or with something to add. > > /Thomas > bugzilla sniplet: notting at redhat.com changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |CLOSED Resolution| |RAWHIDE Fixed In Version| |2.86-2 Additional Comments From notting at redhat.com 2005-12-21 12:25 EST ------- Fixed in -2, it was a new sysvinit bug in 2.86. /Thomas From mailinglists at erwinrol.com Wed Dec 21 18:01:41 2005 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 21 Dec 2005 19:01:41 +0100 Subject: Radeon driver hang In-Reply-To: <43A99259.30305@mharris.ca> References: <1135172630.3105.2.camel@xpc.home.erwinrol.com> <43A99259.30305@mharris.ca> Message-ID: <1135188101.3105.35.camel@xpc.home.erwinrol.com> On Wed, 2005-12-21 at 12:35 -0500, Mike A. Harris wrote: > Erwin Rol wrote: > > Hey all, > > > > I added Benjamin's patch to the ati driver SRPM to test if it works, and > > for me it seems to work, my machine doesn't hard hang anymore. > > > > If you want to try it out the SRPM can be found here; > > http://www.erwinrol.com/downloads/software/xorg-x11-drv-ati-6.5.7-2.src.rpm > > As a good general guideline, if you make a custom version of a package > that Red Hat ships, and bump the release number, it is a very good idea > to also namespace it specially to not conflict with future official > Red Hat package version/releases. It also helps to make it more clear > that it is not an official Red Hat build when looking at the output > of rpm -q et al. > > What I do for personal custom builds of packages, is namespace them with > ".mharris.n" ie: xorg-x11-drv-ati-6.5.7-1.mharris.1.src.rpm > > Let's me know this was based on the official Red Hat -1 package, and it > is my first custom build. If I need to rebuild, it would become .2 on > the end, etc. > > Just thought I'd suggest that, as it's a generally good idea. ;) > > I wouldn't worry about it for this one now tho, as a new Radeon driver > version is about to hit rawhide. Well it wasn't really thought as a replacement of the fedora version, just a quick hack to see it Benjamin's patch worked for me or not. And it did, so I thought to share that in case others had the same problem. I do hope the patch makes it in the next rawhide rpm so i can throw away my hacked rpm :-) - Erwin From stickster at gmail.com Wed Dec 21 18:01:14 2005 From: stickster at gmail.com (Paul W. Frields) Date: Wed, 21 Dec 2005 13:01:14 -0500 Subject: fedora logo shows promise In-Reply-To: References: Message-ID: <1135188074.5629.11.camel@localhost.localdomain> On Tue, 2005-12-20 at 15:34 +0100, Thomas M Steenholdt wrote: > > I've had a big nag against the newly proposed fedora logo for a lot of > > reasons. IMHO the versions that's been on display till now have been > > plain ugly. > > > > Luckily the latest default wallpaper somewhat changes that appearance. > > There is probably still room for improvement, but Diana Fong has done a > > tremendous job in making the logo look a *lot* better. > > > > Just wanted to say thanks! > > Now if we can somehow bring the fedora-logos package with all the icons > and stuff up to speed and make the default theme match these colors - I, > for on, will be very happy with the outcome of the fedora logo "wars". The new design is superswank, Diana's awesome! The only *minor* gripe I have is that the luminance of the background is too high, making text labels on desktop items hard to discern. This'll wow 'em from Wabash to Warsaw. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From enrico.scholz at informatik.tu-chemnitz.de Wed Dec 21 18:17:33 2005 From: enrico.scholz at informatik.tu-chemnitz.de (Enrico Scholz) Date: Wed, 21 Dec 2005 19:17:33 +0100 Subject: rawhide report: 20051221 changes - X server removed In-Reply-To: <43A9912A.6010807@mharris.ca> (Mike A. Harris's message of "Wed, 21 Dec 2005 12:30:18 -0500") References: <64905.194.94.224.254.1135170409.squirrel@jose.freesurf.fr> <43A9912A.6010807@mharris.ca> Message-ID: <87u0d2wc02.fsf@kosh.bigo.ensc.de> mharris at mharris.ca ("Mike A. Harris") writes: > Yeah, after much debate, we decided to move X into Fedora Extras instead > of keeping it in core. However, everyone is going on holidays for 2 > weeks, so it wont show up in Extras probably until mid January or so. > > As an interim workaround, the Linux console can be pretty handy at > times though. Nice to hear. Should solve the one-installation CD problem. And with some optimisations (go back to gcc-2.7 and libc5), we can solve the live-diskette problem too. Thx Enrico From ellson at research.att.com Wed Dec 21 18:29:07 2005 From: ellson at research.att.com (John Ellson) Date: Wed, 21 Dec 2005 13:29:07 -0500 Subject: Status of docbook to pdf toolchain on Fedora? Message-ID: <43A99EF3.9050404@research.att.com> Can someone tell me the status of, or point me to documentation on the docbook xml to pdf toolchain on Fedora? I gather from a 2004 thread in fedora-docs-list that the toolchain was moving to fop, but I don't see any fop yet in core or extras. If you try to install fop separately it requires Jimi or JAI packages from Sun and Sun's installer scripts no longer work on Fedora because somebody broke "tail +n". Probably fixable, but what is the right direction for me to pursue? I tried db2pdf but it seems to expect sgml, rather than xml? John From clydekunkel7734 at cox.net Wed Dec 21 19:17:34 2005 From: clydekunkel7734 at cox.net (Clyde E. Kunkel) Date: Wed, 21 Dec 2005 14:17:34 -0500 Subject: Radeon driver hang In-Reply-To: <1135172630.3105.2.camel@xpc.home.erwinrol.com> References: <1135172630.3105.2.camel@xpc.home.erwinrol.com> Message-ID: <43A9AA4E.10206@cox.net> Erwin Rol wrote: > Hey all, > > I added Benjamin's patch to the ati driver SRPM to test if it works, and > for me it seems to work, my machine doesn't hard hang anymore. > > If you want to try it out the SRPM can be found here; > http://www.erwinrol.com/downloads/software/xorg-x11-drv-ati-6.5.7-2.src.rpm > > - Erwin > > > > Hi, Does this patch fix/address dual radeon card probs? I have an AGP and PCI radeon 9200 and 9200SE respectively and can't get dual to work with Fedora, but can with SuSE and Gentoo. -- Regards, Old Fart From mailinglists at erwinrol.com Wed Dec 21 19:26:28 2005 From: mailinglists at erwinrol.com (Erwin Rol) Date: Wed, 21 Dec 2005 20:26:28 +0100 Subject: Radeon driver hang In-Reply-To: <43A9AA4E.10206@cox.net> References: <1135172630.3105.2.camel@xpc.home.erwinrol.com> <43A9AA4E.10206@cox.net> Message-ID: <1135193189.3105.48.camel@xpc.home.erwinrol.com> On Wed, 2005-12-21 at 14:17 -0500, Clyde E. Kunkel wrote: > Erwin Rol wrote: > > Hey all, > > > > I added Benjamin's patch to the ati driver SRPM to test if it works, and > > for me it seems to work, my machine doesn't hard hang anymore. > > > > If you want to try it out the SRPM can be found here; > > http://www.erwinrol.com/downloads/software/xorg-x11-drv-ati-6.5.7-2.src.rpm > > > Hi, > > Does this patch fix/address dual radeon card probs? I have an AGP and > PCI radeon 9200 and 9200SE respectively and can't get dual to work with > Fedora, but can with SuSE and Gentoo. I have no idea, I only know that my computer froze hard as soon as i logged in unless i switched off all acceleration. With this patch it doesn't freeze anymore, with acceleration enabled. For more information you probably best can ask the Xorg-devel list, since i just made a SRPM out the patch nothing more. - Erwin From vonbrand at inf.utfsm.cl Wed Dec 21 19:28:53 2005 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Wed, 21 Dec 2005 16:28:53 -0300 Subject: Everything installs In-Reply-To: Your message of "Wed, 21 Dec 2005 09:42:01 CDT." <43A969B9.4060200@cornell.edu> Message-ID: <200512211928.jBLJSrSx005248@laptop11.inf.utfsm.cl> Paul A Houle wrote: [...] > I recently got Linux running on a Sun Ultra 10, and I chose > Debian because it's one of the few distributions that will easily > install on SPARC. Since you are here, may I point you at Aurora 2.0beta2 (loosely based on Fedora 3) runs OK here on my Ultra 1. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From jkeating at redhat.com Wed Dec 21 19:38:29 2005 From: jkeating at redhat.com (Jesse Keating) Date: Wed, 21 Dec 2005 11:38:29 -0800 Subject: Another round of java rebuilds Message-ID: <1135193909.10390.46.camel@yoda.loki.me> A gcc bug was found that is triggered by some of the java packages. This has been fixed so I am starting another round of java rebuilds. It remains to be seen if all java packages will rebuild cleanly this time around. I do believe jonas and jacorb were the only ones left after last time. -- Jesse Keating Release Engineer: Fedora -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From mharris at mharris.ca Wed Dec 21 20:03:49 2005 From: mharris at mharris.ca (Mike A. Harris) Date: Wed, 21 Dec 2005 15:03:49 -0500 Subject: rawhide report: 20051221 changes - X server removed In-Reply-To: <87u0d2wc02.fsf@kosh.bigo.ensc.de> References: <64905.194.94.224.254.1135170409.squirrel@jose.freesurf.fr> <43A9912A.6010807@mharris.ca> <87u0d2wc02.fsf@kosh.bigo.ensc.de> Message-ID: <43A9B525.6020104@mharris.ca> Enrico Scholz wrote: > mharris at mharris.ca ("Mike A. Harris") writes: > > >>Yeah, after much debate, we decided to move X into Fedora Extras instead >>of keeping it in core. However, everyone is going on holidays for 2 >>weeks, so it wont show up in Extras probably until mid January or so. >> >>As an interim workaround, the Linux console can be pretty handy at >>times though. > > > Nice to hear. Should solve the one-installation CD problem. And with > some optimisations (go back to gcc-2.7 and libc5), we can solve the > live-diskette problem too. That's actually not planned to happen until FC6, as the a.out support is a bit too rough around the edges currently. Also, it's dependent on features in the 1.2.14 kernel which hasn't yet been released. (DRM integration issues, etc.) -- Mike A. Harris, Open Source Advocate * http://mharris.ca Proud to be Canadian. From dmalcolm at redhat.com Wed Dec 21 20:23:15 2005 From: dmalcolm at redhat.com (David Malcolm) Date: Wed, 21 Dec 2005 15:23:15 -0500 Subject: rawhide report: 20051221 changes - X server removed In-Reply-To: <43A9B525.6020104@mharris.ca> References: <64905.194.94.224.254.1135170409.squirrel@jose.freesurf.fr> <43A9912A.6010807@mharris.ca> <87u0d2wc02.fsf@kosh.bigo.ensc.de> <43A9B525.6020104@mharris.ca> Message-ID: <1135196595.25397.18.camel@cassandra.boston.redhat.com> On Wed, 2005-12-21 at 15:03 -0500, Mike A. Harris wrote: > Enrico Scholz wrote: > > mharris at mharris.ca ("Mike A. Harris") writes: > > > > > >>Yeah, after much debate, we decided to move X into Fedora Extras instead > >>of keeping it in core. However, everyone is going on holidays for 2 > >>weeks, so it wont show up in Extras probably until mid January or so. > >> > >>As an interim workaround, the Linux console can be pretty handy at > >>times though. > > > > > > Nice to hear. Should solve the one-installation CD problem. And with > > some optimisations (go back to gcc-2.7 and libc5), we can solve the > > live-diskette problem too. > > That's actually not planned to happen until FC6, as the a.out > support is a bit too rough around the edges currently. Also, > it's dependent on features in the 1.2.14 kernel which hasn't > yet been released. (DRM integration issues, etc.) Isn't the plan to move the kernel to Extras? From alan at clueserver.org Wed Dec 21 21:35:07 2005 From: alan at clueserver.org (alan) Date: Wed, 21 Dec 2005 13:35:07 -0800 (PST) Subject: kernel 2.6.14-1.1777_FC5 for x86_64 doubleplus ungood Message-ID: Just updated to the latest kernel. irqs no longer are visable to the kernel. Eth0 has an irq 0 and is unable to do much of anything. (But gives no useful error messages.) The nvidia closed source module actually gives a useful message about not being able to find the irq for the card. lspci shows all the expected devices. Nothing has an irq in dmesg however. pci=routeirqs does nothing to help. This is running on an HP zv5200z with an AMD64 3700+ with a gig of ram. Need any more info. -- "George W. Bush -- Bringing back the Sixties one Nixon at a time." From twaugh at redhat.com Wed Dec 21 21:43:25 2005 From: twaugh at redhat.com (Tim Waugh) Date: Wed, 21 Dec 2005 21:43:25 +0000 Subject: Status of docbook to pdf toolchain on Fedora? In-Reply-To: <43A99EF3.9050404@research.att.com> References: <43A99EF3.9050404@research.att.com> Message-ID: <20051221214325.GG16000@redhat.com> On Wed, Dec 21, 2005 at 01:29:07PM -0500, John Ellson wrote: > I gather from a 2004 thread in fedora-docs-list that the toolchain was > moving to fop, > but I don't see any fop yet in core or extras. Basically the toolchain is still more or less broken for PDF I'm afraid. > If you try to install fop separately it requires Jimi or JAI > packages from Sun and Sun's installer scripts no longer work on > Fedora because somebody broke "tail +n". Probably fixable, but what > is the right direction for me to pursue? export _POSIX2_VERSION=199209 .. or ask Sun to fix their script to use 'tail -n +...'. See: info coreutils "Standards Conformance" > I tried db2pdf but it seems to expect sgml, rather than xml? Yes, that's for SGML. Tim. */ -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From ellson at research.att.com Wed Dec 21 21:53:13 2005 From: ellson at research.att.com (John Ellson) Date: Wed, 21 Dec 2005 16:53:13 -0500 Subject: kernel 2.6.14-1.1777_FC5 for x86_64 doubleplus ungood In-Reply-To: References: Message-ID: <43A9CEC9.2060108@research.att.com> alan wrote: > Just updated to the latest kernel. > > irqs no longer are visable to the kernel. > > Eth0 has an irq 0 and is unable to do much of anything. (But gives no > useful error messages.) > > The nvidia closed source module actually gives a useful message about not > being able to find the irq for the card. > > lspci shows all the expected devices. Nothing has an irq in dmesg > however. pci=routeirqs does nothing to help. > > This is running on an HP zv5200z with an AMD64 3700+ with a gig of ram. > > Need any more info. > > See: bug# 176284 Try: acpi=off irqpoll John From paul at all-the-johnsons.co.uk Wed Dec 21 21:53:33 2005 From: paul at all-the-johnsons.co.uk (Paul F. Johnson) Date: Wed, 21 Dec 2005 21:53:33 +0000 Subject: kernel 2.6.14-1.1777_FC5 for x86_64 doubleplus ungood In-Reply-To: References: Message-ID: <1135202013.3232.13.camel@T7.Linux> Hi, > Just updated to the latest kernel. > > irqs no longer are visable to the kernel. This was happening in the the 1775 kernel as well for x86_64. Time to bugzilla it I think. You wanna do it? TTFN Paul -- main(t,_,a) char*a;{return!0 References: <1134921889.11021.47.camel@localhost.localdomain> <604aa7910512180940v3884a78byfc5445eb0e7dbed2@mail.gmail.com> <1134956408.11021.69.camel@localhost.localdomain> <43A6A655.6080400@redhat.com> <43A6B8C7.5080008@mesias.co.uk> <1135008339.28062.0.camel@yoda.loki.me> <1135008807.14566.38.camel@gilboa-work-dev> <20051219162103.GG31712@ryoko.camperquake.de> Message-ID: <1135206372.26711.13.camel@hamburger.booze> On Mon, 2005-12-19 at 17:21 +0100, Ralf Ertzinger wrote: > > Plus, I might be wrong here, but doesn't suspend to disk theoretically > > allows you to suspend, switch to Windows (*spit!), and pick up where you > > left once you switch back to Linux? > > As long as windows leaves the Linux partitions alone that should work. And if Linux leaves the Windows partitions alone. -------------- 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 Wed Dec 21 23:19:53 2005 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Wed, 21 Dec 2005 16:19:53 -0700 Subject: Enable sqlite database backend in QT In-Reply-To: <43A8CF19.6070909@develer.com> References: <43A8CF19.6070909@develer.com> Message-ID: <200512211619.58034.lamont@gurulabs.com> On Tuesday 20 December 2005 08:42pm, Bernardo Innocenti wrote: > Hello, > > the sqlite plugin for Qt isn't built on Fedora. Unless > there's a good reason, I'd like to propose the following > spec change to create the missing package. +1 > Patch by Lorenzo Mancini . > > > --- SPECS/qt.spec.orig 2005-12-20 23:58:40.000000000 +0100 > +++ SPECS/qt.spec 2005-12-21 01:38:20.000000000 +0100 > @@ -31,6 +31,9 @@ > # buildodbc: Build ODBC plugins > %define buildodbc 1 > > +# buildsqlite: Build SQLite plugins > +%define buildsqlite 1 > + > # buildmt: Build libs with threading support > %define buildmt 1 > > @@ -77,7 +80,13 @@ > %define plugin_odbc %{nil} > %endif > > -%define plugins %{plugin_mysql} %{plugin_psql} %{plugin_odbc} > %{plugins_style} +%if %{buildsqlite} > +%define plugin_sqlite -plugin-sql-sqlite > +%else > +%define plugin_sqlite %{nil} > +%endif > + > +%define plugins %{plugin_mysql} %{plugin_psql} %{plugin_odbc} > %{plugin_sqlite} %{plugins_style} > > Summary: The shared library for the Qt GUI toolkit. > Name: qt > @@ -169,6 +178,10 @@ > BuildRequires: unixODBC-devel > %endif > > +%if %{buildsqlite} > +BuildRequires: sqlite2-devel > +%endif > + > BuildRequires: fontconfig-devel >= 2.0 > > > @@ -224,6 +237,14 @@ > %endif > > > +%if %{buildsqlite} > +%package SQLite > +Summary: SQLite drivers for Qt's SQL classes. > +Group: System Environment/Libraries > +Requires: %{name} = %{epoch}:%{version}-%{release} > +%endif > + > + > %package static > Summary: Version of the Qt GUI toolkit for static linking > Group: Development/Libraries > @@ -296,6 +317,10 @@ > PostgreSQL driver for Qt's SQL classes (QSQL) > %endif > > +%if %{buildsqlite} > +%description SQLite > +SQLite driver for Qt's SQL classes (QSQL) > +%endif > > %description designer > The qt-designer package contains an User Interface designer tool > @@ -447,6 +472,13 @@ > popd > %endif > > +# build sqlite plugin > +%if %{buildsqlite} > + pushd plugins/src/sqldrivers/sqlite > + qmake -o Makefile "LIBS+=-lsqlite" sqlite.pro > + popd > +%endif > + > make $SMP_MFLAGS src-moc > make $SMP_MFLAGS sub-src > make $SMP_MFLAGS sub-tools UIC="$QTDIR/bin/uic -nostdlib -L > $QTDIR/plugins" @@ -693,6 +725,11 @@ > %{qtdir}/plugins/sqldrivers/libqsqlmysql* > %endif > > +%if %{buildsqlite} > +%files SQLite > +%defattr(-,root,root,-) > +%{qtdir}/plugins/sqldrivers/libqsqlite* > +%endif > > %files designer > %defattr(-,root,root,-) WFM/Looks good to me, but, my opinion doesn't get a vote on these things. -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From dmalcolm at redhat.com Wed Dec 21 23:33:01 2005 From: dmalcolm at redhat.com (David Malcolm) Date: Wed, 21 Dec 2005 18:33:01 -0500 Subject: Status of docbook to pdf toolchain on Fedora? In-Reply-To: <20051221214325.GG16000@redhat.com> References: <43A99EF3.9050404@research.att.com> <20051221214325.GG16000@redhat.com> Message-ID: <1135207981.25397.31.camel@cassandra.boston.redhat.com> On Wed, 2005-12-21 at 21:43 +0000, Tim Waugh wrote: > On Wed, Dec 21, 2005 at 01:29:07PM -0500, John Ellson wrote: > > > I gather from a 2004 thread in fedora-docs-list that the toolchain was > > moving to fop, > > but I don't see any fop yet in core or extras. > > Basically the toolchain is still more or less broken for PDF I'm > afraid. There seems to be some progress is this area, according to this post: https://www.redhat.com/archives/fedora-docs-list/2005-December/msg00017.html > > > If you try to install fop separately it requires Jimi or JAI > > packages from Sun and Sun's installer scripts no longer work on > > Fedora because somebody broke "tail +n". Probably fixable, but what > > is the right direction for me to pursue? > > export _POSIX2_VERSION=199209 > > .. or ask Sun to fix their script to use 'tail -n +...'. > > See: > info coreutils "Standards Conformance" > > > I tried db2pdf but it seems to expect sgml, rather than xml? > > Yes, that's for SGML. > > Tim. > */ > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list From ellson at research.att.com Thu Dec 22 01:11:13 2005 From: ellson at research.att.com (John Ellson) Date: Wed, 21 Dec 2005 20:11:13 -0500 Subject: Status of docbook to pdf toolchain on Fedora? In-Reply-To: <1135207981.25397.31.camel@cassandra.boston.redhat.com> References: <43A99EF3.9050404@research.att.com> <20051221214325.GG16000@redhat.com> <1135207981.25397.31.camel@cassandra.boston.redhat.com> Message-ID: <43A9FD31.9030903@research.att.com> David Malcolm wrote: > On Wed, 2005-12-21 at 21:43 +0000, Tim Waugh wrote: > >> On Wed, Dec 21, 2005 at 01:29:07PM -0500, John Ellson wrote: >> >> >>> I gather from a 2004 thread in fedora-docs-list that the toolchain was >>> moving to fop, >>> but I don't see any fop yet in core or extras. >>> >> Basically the toolchain is still more or less broken for PDF I'm >> afraid. >> > > There seems to be some progress is this area, according to this post: > https://www.redhat.com/archives/fedora-docs-list/2005-December/msg00017.html > > > > I grabbed the latest FOP trunk from svn, but it still seems to have Sun dependencies. Ant spent a while crunching with gij, then: BUILD FAILED /home/ellson/FIX/Linux.x86_64/build/fop/trunk/build.xml:368: Unable to find a javac compiler; com.sun.tools.javac.Main is not on the classpath. Perhaps JAVA_HOME does not point to the JDK I don't know anything about java development, so I don't understand why it couldn't find the javac that is in /usr/bin/javac. I set "JAVA_HOME=/usr" Is that reasonable on Fedora? It says to point it at the JDK. What JDK? (I'm up to date with today's rawhide.) John From pemboa at gmail.com Thu Dec 22 02:44:24 2005 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 21 Dec 2005 20:44:24 -0600 Subject: fedora logo shows promise In-Reply-To: References: Message-ID: <16de708d0512211844o45208d5ajeb2bf4b3c5e3f9aa@mail.gmail.com> Sorry to jump into this conversation, but where can these new logos without haing to use CVS or such, just som simple archive download or direct download would be preferable. On 12/20/05, Thomas M Steenholdt wrote: > > I've had a big nag against the newly proposed fedora logo for a lot of > reasons. IMHO the versions that's been on display till now have been > plain ugly. > > Luckily the latest default wallpaper somewhat changes that appearance. > There is probably still room for improvement, but Diana Fong has done a > tremendous job in making the logo look a *lot* better. > > Just wanted to say thanks! > > /Thomas > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jspaleta at gmail.com Thu Dec 22 02:47:38 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Wed, 21 Dec 2005 21:47:38 -0500 Subject: fedora logo shows promise In-Reply-To: <16de708d0512211844o45208d5ajeb2bf4b3c5e3f9aa@mail.gmail.com> References: <16de708d0512211844o45208d5ajeb2bf4b3c5e3f9aa@mail.gmail.com> Message-ID: <604aa7910512211847s3087e22ag38492ca49c57f920@mail.gmail.com> On 12/21/05, Arthur Pemberton wrote: > Sorry to jump into this conversation, but where can these new logos without > haing to use CVS or such, just som simple archive download or direct > download would be preferable. you must get permission to use the logo see http://fedoraproject.org/wiki/Marketing/Logo for instructions on how to get permission -jef From pemboa at gmail.com Thu Dec 22 02:56:51 2005 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 21 Dec 2005 20:56:51 -0600 Subject: fedora logo shows promise In-Reply-To: <604aa7910512211847s3087e22ag38492ca49c57f920@mail.gmail.com> References: <16de708d0512211844o45208d5ajeb2bf4b3c5e3f9aa@mail.gmail.com> <604aa7910512211847s3087e22ag38492ca49c57f920@mail.gmail.com> Message-ID: <16de708d0512211856g48a7d2d6vb82ea87b4247fb33@mail.gmail.com> Thanks. On 12/21/05, Jeff Spaleta wrote: > > On 12/21/05, Arthur Pemberton wrote: > > Sorry to jump into this conversation, but where can these new logos > without > > haing to use CVS or such, just som simple archive download or direct > > download would be preferable. > > you must get permission to use the logo see > http://fedoraproject.org/wiki/Marketing/Logo > for instructions on how to get permission > > -jef > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sopwith at redhat.com Thu Dec 22 03:30:00 2005 From: sopwith at redhat.com (Elliot Lee) Date: Wed, 21 Dec 2005 22:30:00 -0500 (EST) Subject: fedora logo shows promise In-Reply-To: <16de708d0512211844o45208d5ajeb2bf4b3c5e3f9aa@mail.gmail.com> References: <16de708d0512211844o45208d5ajeb2bf4b3c5e3f9aa@mail.gmail.com> Message-ID: > On 12/20/05, Thomas M Steenholdt wrote: > > > > I've had a big nag against the newly proposed fedora logo for a lot of > > reasons. IMHO the versions that's been on display till now have been > > plain ugly. > > > > Luckily the latest default wallpaper somewhat changes that appearance. > > There is probably still room for improvement, but Diana Fong has done a > > tremendous job in making the logo look a *lot* better. Actually, I think the modified logo builds a connection between Fedora and the "cheap plastic" look. Not something you want for a project that needs to change the world. :) Best, -- Elliot Red Hat Summit Nashville (May 30 - June 2, 2006) http://www.redhat.com/promo/summit/ From pemboa at gmail.com Thu Dec 22 03:34:41 2005 From: pemboa at gmail.com (Arthur Pemberton) Date: Wed, 21 Dec 2005 21:34:41 -0600 Subject: fedora logo shows promise In-Reply-To: References: <16de708d0512211844o45208d5ajeb2bf4b3c5e3f9aa@mail.gmail.com> Message-ID: <16de708d0512211934k76f0a585k32bb1e2fbd5a841a@mail.gmail.com> Well blue happens to be my favourite color :) On 12/21/05, Elliot Lee wrote: > > > On 12/20/05, Thomas M Steenholdt wrote: > > > > > > I've had a big nag against the newly proposed fedora logo for a lot of > > > reasons. IMHO the versions that's been on display till now have been > > > plain ugly. > > > > > > Luckily the latest default wallpaper somewhat changes that appearance. > > > There is probably still room for improvement, but Diana Fong has done > a > > > tremendous job in making the logo look a *lot* better. > > Actually, I think the modified logo builds a connection between Fedora and > the "cheap plastic" look. Not something you want for a project that needs > to change the world. :) > > Best, > -- Elliot > Red Hat Summit Nashville (May 30 - June 2, 2006) > http://www.redhat.com/promo/summit/ > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bojan at rexursive.com Thu Dec 22 04:45:01 2005 From: bojan at rexursive.com (Bojan Smojver) Date: Thu, 22 Dec 2005 15:45:01 +1100 Subject: GnuCash Message-ID: <20051222154501.ycba3ysmos0k0sk0@imp.rexursive.com> Any chance someone can bump up GnuCash in Rawhide? There seems to be a new version in FC4 updates (testing)... Thanks, -- Bojan From sundaram at redhat.com Thu Dec 22 04:46:33 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 22 Dec 2005 10:16:33 +0530 Subject: Status of docbook to pdf toolchain on Fedora? In-Reply-To: <43A9FD31.9030903@research.att.com> References: <43A99EF3.9050404@research.att.com> <20051221214325.GG16000@redhat.com> <1135207981.25397.31.camel@cassandra.boston.redhat.com> <43A9FD31.9030903@research.att.com> Message-ID: <43AA2FA9.6010201@redhat.com> Hi > I grabbed the latest FOP trunk from svn, but it still seems to have > Sun dependencies. Ant spent a while > crunching with gij, then: > > BUILD FAILED > /home/ellson/FIX/Linux.x86_64/build/fop/trunk/build.xml:368: Unable > to find a javac compiler; > com.sun.tools.javac.Main is not on the classpath. > Perhaps JAVA_HOME does not point to the JDK > > I don't know anything about java development, so I don't understand > why it couldn't find the > javac that is in /usr/bin/javac. > > I set "JAVA_HOME=/usr" Is that reasonable on Fedora? It says to > point it at the JDK. What JDK? > > (I'm up to date with today's rawhide.) > Might post to the fedora-docs-list. http://fedoraproject.org/wiki/Communicate -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From sundaram at redhat.com Thu Dec 22 04:48:01 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 22 Dec 2005 10:18:01 +0530 Subject: GnuCash In-Reply-To: <20051222154501.ycba3ysmos0k0sk0@imp.rexursive.com> References: <20051222154501.ycba3ysmos0k0sk0@imp.rexursive.com> Message-ID: <43AA3001.5060009@redhat.com> Bojan Smojver wrote: > Any chance someone can bump up GnuCash in Rawhide? There seems to be a > new version in FC4 updates (testing)... > > Thanks, Kindly file a RFE against the package in http://bugzilla.redhat.com. Not all of the package maintainers are necessarily subscribed to this list. -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From bojan at rexursive.com Thu Dec 22 04:59:10 2005 From: bojan at rexursive.com (Bojan Smojver) Date: Thu, 22 Dec 2005 15:59:10 +1100 Subject: GnuCash Message-ID: <20051222155910.edw5dhwazo88wc8c@imp.rexursive.com> Bugzilla #176397. -- Bojan From notting at redhat.com Thu Dec 22 06:27:59 2005 From: notting at redhat.com (Bill Nottingham) Date: Thu, 22 Dec 2005 01:27:59 -0500 Subject: GnuCash In-Reply-To: <20051222154501.ycba3ysmos0k0sk0@imp.rexursive.com> References: <20051222154501.ycba3ysmos0k0sk0@imp.rexursive.com> Message-ID: <20051222062758.GB6076@devserv.devel.redhat.com> Bojan Smojver (bojan at rexursive.com) said: > Any chance someone can bump up GnuCash in Rawhide? There seems to be a > new version in FC4 updates (testing)... Working on the entertaining aq* dependencies first. :) Bill From m.f.h at web.de Thu Dec 22 07:03:54 2005 From: m.f.h at web.de (Marcus Hartig) Date: Thu, 22 Dec 2005 08:03:54 +0100 Subject: something's uninstalling the sun jre, again In-Reply-To: <43A8C86A.2040308@redhat.com> References: <1135121763.4131.50.camel@yoda.loki.me> <43A8C86A.2040308@redhat.com> Message-ID: <43AA4FDA.6090508@web.de> Warren Togami wrote: > Yes, this is because Sun is not cooperating with the community on RPM > packaging standards. If you want a Sun java RPM that integrates well > into Fedora, you should build one from jpackage.org. Warren, which Java (Version) package do you recommend for Fedora, that I must no edit all the symlinks in /etc/alternatives? I'm aiming to use opencms 6.03 with tomcat, apache, firefox (java plugin) and need opencms for a new job next year. :-) Marcus From m.f.h at web.de Thu Dec 22 07:13:19 2005 From: m.f.h at web.de (Marcus Hartig) Date: Thu, 22 Dec 2005 08:13:19 +0100 Subject: fedora logo shows promise In-Reply-To: <1135188074.5629.11.camel@localhost.localdomain> References: <1135188074.5629.11.camel@localhost.localdomain> Message-ID: <43AA520F.5090509@web.de> Paul W. Frields wrote: > The new design is superswank, Diana's awesome! The only *minor* gripe I > have is that the luminance of the background is too high, making text > labels on desktop items hard to discern. This'll wow 'em from Wabash to > Warsaw. If you disable the shadow text on desktop icons/labels, then it looks very fine. Marcus From buildsys at redhat.com Thu Dec 22 08:13:01 2005 From: buildsys at redhat.com (Build System) Date: Thu, 22 Dec 2005 03:13:01 -0500 Subject: rawhide report: 20051222 changes Message-ID: <200512220813.jBM8D1Yb018993@porkchop.devel.redhat.com> Updated Packages: SysVinit-2.86-2 --------------- * Wed Dec 21 2005 Bill Nottingham - 2.86-2 - fix single user mode (#176348) ant-0:1.6.5-1jpp_2fc -------------------- * Wed Dec 21 2005 Jesse Keating - 0:1.6.5-1jpp_2fc - rebuilt again antlr-0:2.7.4-2jpp_5fc ---------------------- * Wed Dec 21 2005 Jesse Keating - 0:2.7.4-2jpp_5fc - rebuilt for new gcj bcel-0:5.1-1jpp_5fc ------------------- * Wed Dec 21 2005 Jesse Keating - 0:5.1-1jpp_5fc - rebuilt again bind-30:9.3.2-1 --------------- * Wed Dec 21 2005 Jason Vas Dias - 30:9.3.2-1 - Upgrade to 9.3.2, released today bridge-utils-1.0.6-1 -------------------- * Wed Dec 21 2005 David Woodhouse 1.0.6-1 - Update to 1.0.6 - Cleanups from Matthias Saou (#172774) cairo-java-1.0.1-4 ------------------ * Wed Dec 21 2005 Jesse Keating - 1.0.0-4 - rebuilt again classpathx-jaf-0:1.0-2jpp_4fc ----------------------------- * Wed Dec 21 2005 Jesse Keating 0:1.0-2jpp_4fc - rebuilt classpathx-mail-0:1.0-4jpp_4fc ------------------------------ * Wed Dec 21 2005 Jesse Keating - 0:1.0-4jpp_4fc - rebuilt cryptix-0:3.2.0-4jpp_3fc ------------------------ * Wed Dec 21 2005 Jesse Keating 3.2.0-4jpp_3fc - rebuilt again cvs-1.11.21-3 ------------- * Wed Dec 21 2005 Martin Stransky 1.11.21-3 - fix for #150031 - cvs diff -kk -u fails dtdparser-0:1.21-2jpp_3fc ------------------------- * Wed Dec 21 2005 Jesse Keating - 0:1.21-2jpp_3fc - rebuilt again fontconfig-2.3.93-2 ------------------- * Wed Dec 21 2005 Carl Worth - 2.3.93-2 - Fix to create /var/cache/fontconfig/stamp in the post install stage. * Wed Dec 21 2005 Carl Worth - 2.3.93-1 - New upstream version. gaim-1:1.5.0-9.fc5.3 -------------------- * Wed Dec 21 2005 Warren Togami - rebuild for nss-devel (#176314 nosnilmot) gcc-4.1.0-0.10 -------------- * Wed Dec 21 2005 Jakub Jelinek 4.1.0-0.10 - update from gcc-4_1-branch (-r108539:108861) - PRs ada/18659, ada/18819, c++/20552, c++/21228, c++/24278, c++/24915, fortran/18197, fortran/25458, libgfortran/25039, libgfortran/25264, libgfortran/25349, libobjc/14382, libstdc++/25421, middle-end/22313, middle-end/24306, rtl-optimization/23837, rtl-optimization/25224, rtl-optimization/25310, target/24969, testsuite/25215, tree-optimization/23838, tree-optimization/24378 - update from gomp-20050608-branch (up to -r108859) - fix _Pragma handling (Richard Henderson, PR preprocessor/25240) - fix reload re-recognition of insns (Alan Modra, PR rtl-optimization/25432) - don't peephole RTX_FRAME_RELATED_P insns (Andrew Haley, PR middle-end/25121) * Thu Dec 15 2005 Jakub Jelinek 4.1.0-0.9 - fix OpenMP lastprivate handling for global vars (Aldy Hernandez) - fix gnu.xml.dom.DomNode's detach method (Caolan McNamara, PR classpath/25426) - fix up the #175569 fix (Tom Tromey, #175833, PR java/25429) - fix strength reduction miscompilation of libgnomecanvas (#175669, PR rtl-optimization/24899) - create libgcj-*.jar with - at E options and feed a sorted list to it rather than relying on filesystem sorting * Wed Dec 14 2005 Jakub Jelinek 4.1.0-0.8 - update from gcc-4_1-branch (-r108414:108539) - PRs classpath/25389, fortran/23815, fortran/25078, target/25254 - fix Java ICE on initialized static final var used in case (Andrew Haley, #175569, PR java/25429) - fix crash in _Unwind_IteratePhdrCallback (Andrew Haley) - don't Require alsa-lib-devel, just BuildRequire it (#175627) - use .gnu.linkonce.d.rel.ro.* sections for objects that are constant after relocation processing gedit-1:2.13.0-3 ---------------- * Wed Dec 21 2005 Jeremy Katz - 1:2.13.0-3 - fix gedit-devel requirement to include epoch gimp-print-4.2.7-15 ------------------- * Wed Dec 21 2005 Tim Waugh 4.2.7-15 - Fix PPD translations (bug #176086). - Fix Spanish po file (bug #176214). glib-java-0.2.1-3.5 ------------------- * Wed Dec 21 2005 Jesse Keating 0 9.2.1-3.5 - rebuilt glibc-2.3.90-22 --------------- * Wed Dec 21 2005 Jakub Jelinek 2.3.90-22 - update from CVS - minor fts fixes - revert broken _Pragma () workaround - fix ldconfig on bi-arch architectures (#176316) gnome-panel-2.13.3-3 -------------------- * Wed Dec 21 2005 Ray Strode 2.13.3-3 - add patch from cvs to fix crasher bug gnome-themes-2.13.2-3 --------------------- * Wed Dec 21 2005 Matthias Clasen - 2.13.2-3 - Make sure the new Clearlooks metacity theme gets picked up gnu-crypto-0:2.0.1-1jpp_11fc ---------------------------- * Wed Dec 21 2005 Gary Benson - 0:2.0.1-1jpp_11fc - Rebuild again gnu.getopt-0:1.0.9-4jpp_3fc --------------------------- * Wed Dec 21 2005 Jesse Keating 0:1.0.9-4jpp_3fc - rebuilt again gnu.regexp-0:1.1.4-7jpp_2fc --------------------------- * Wed Dec 21 2005 Jesse Keating 0:1.1.4-7jpp_2fc - rebuilt again hplip-0.9.7-4 ------------- * Wed Dec 21 2005 Tim Waugh 0.9.7-4 - Build requires python-devel, libjpeg-devel (bug #176317). imake-1.0.0-4 ------------- * Wed Dec 21 2005 Than Ngo 1.0.0-4 - final fix for #173593 initscripts-8.20-1 ------------------ * Wed Dec 21 2005 Bill Nottingham 8.20-1 - remove kmodule. udev handles module loading now - require appropriate udev * Thu Dec 15 2005 Bill Nottingham 8.19-1 - Require syslog, for alternate implementations thereof (#172885) - Fix fsck invocation for weeding out netdev devices (#175803) * Fri Dec 02 2005 Bill Nottingham 8.18-1 - use new dhclient file paths, add appropriate conflict (#169164) jakarta-commons-codec-0:1.3-2jpp_2fc ------------------------------------ * Wed Dec 21 2005 Jesse Keating 0:1.3-2jpp_2fc - rebuilt again jakarta-commons-collections-0:3.1-2jpp_3fc ------------------------------------------ * Wed Dec 21 2005 Jesse Keating 0:3.1-2jpp_3fc - rebuilt again jakarta-commons-dbcp-0:1.2.1-3jpp_3fc ------------------------------------- * Wed Dec 21 2005 Jesse Keating - 0:1.2.1-3jpp_3fc - rebuilt again jakarta-commons-lang-0:2.0-2jpp_3fc ----------------------------------- * Wed Dec 21 2005 Jesse Keating - 0:2.0-2jpp_3fc - rebuilt again jakarta-commons-launcher-0:0.9-3jpp_2fc --------------------------------------- * Tue Dec 13 2005 Jesse Keating - 0:0.9-3jpp_2fc - rebuilt for new gcj * Fri Dec 09 2005 Jesse Keating - rebuilt * Thu Jan 20 2005 Gary Benson - 0:0.9-3jpp_1fc - Build into Fedora. jakarta-commons-pool-0:1.2-2jpp_3fc ----------------------------------- * Wed Dec 21 2005 Jesse Keating - 0:1.2-2jpp_3fc - rebuilt again java-1.4.2-gcj-compat-0:1.4.2.0-40jpp_57rh ------------------------------------------ * Wed Dec 21 2005 Jesse Keating - 0:1.4.2.0-40jpp_57rh - rebuilt again w/ another new gcc javacc-0:3.2-1jpp_4fc --------------------- * Wed Dec 21 2005 Jesse Keating 0:3.2-1jpp_4fc - rebuilt jlex-0:1.2.6-1jpp_3fc --------------------- * Wed Dec 21 2005 Jesse Keating 1.2.6-1jpp_3fc - rebuilt again jpackage-utils-0:1.6.3-1jpp_3rh ------------------------------- * Wed Dec 21 2005 Jesse Keating 0:1.6.3-1jpp_3rh - Bump release number and rebuild for yet another new gcc jsch-0:0.1.18-1jpp_4fc ---------------------- * Wed Dec 21 2005 Andrew Overholt 0.1.18-1jpp_4fc - Rebuild again junit-0:3.8.1-3jpp_6fc ---------------------- * Wed Dec 21 2005 Jesse Keating 0:3.8.1-3jpp_6fc - rebuilt again kdelibs-6:3.5.0-4 ----------------- * Wed Dec 21 2005 Than Ngo 6:3.5.0-4 - apply patch to fix crash in kicker on KDE logout kernel-xen-2.6.14-1.21_FC5 -------------------------- * Tue Dec 20 2005 Juan Quintela - switch BSD license to Dual BSD/GPL as agreed with upstream. * Tue Dec 20 2005 Juan Quintela - add EXPORT_SYMBOL for xen_net_read_mac. * Tue Dec 20 2005 Juan Quintela - xennet is a module again. - merge with rawhide 1.7776 kernel. - HIGHMEM4G is default now. lftp-3.3.5-4 ------------ * Wed Dec 21 2005 Jason Vas Dias - 3.3.5-4 - fix bug 176315: openssl libraries not being picked up - gnutls was instead - improvements to bug 172376 fix libgnomeprint22-2.12.1-4 ------------------------ * Wed Dec 21 2005 Kristian H??gsberg 2.12.1-4 - Spec file clean-ups from from Matthias Saou (#172923): - Explicitly disable rpath. - Exclude static modules from the main package. - Exclude static libraries from the devel package (useless). - Don't own entire /usr/share/gtk-doc. - Remove explicit pre/post /sbin/ldconfig deps (they're automatic with -p). - Change PreReqs to more correct Requires. - Fix devel summary. - Add _smp_mflags to build. linux-atm-2.5.0-0.20050118.3 ---------------------------- * Wed Dec 21 2005 David Woodhouse 2.5.0-0.20050118.3 - Package cleanups from Matthias Saou (#172932): - Add missing /sbin/ldconfig calls for the libs package. - Tag atmsigd.conf config file as noreplace. - Remove INSTALL (dangling symlink) from %doc. - Don't include Makefile* file from doc/. - Don't include both sgml and txt howto (only txt). - Minor spec file cleanups. log4j-0:1.2.8-7jpp_7fc ---------------------- * Wed Dec 21 2005 Jesse Keating 0:1.2.8-7jpp7fc - rebuilt again lucene-0:1.4.3-1jpp_11fc ------------------------ * Wed Dec 21 2005 Gary Benson - 0:1.4.3-1jpp_10fc - Rebuilt again man-pages-ja-20051215-1 ----------------------- * Wed Dec 21 2005 Akira TAGOH - 20051215-1 - updates to 20051215. mesa-6.4.1-2 ------------ * Tue Dec 20 2005 Mike A. Harris 6.4.1-2 - Rebuild to ensure libGLU gets rebuilt with new gcc with C++ compiler fixes. - Changed the 3 devel packages to use Obsoletes instead of Conflicts for the packages the files used to be present in, as this is more friendy for OS upgrades. - Added "Requires: libX11-devel" to mesa-libGL-devel package (#173712) - Added "Requires: libGL-devel" to mesa-libGLU-devel package (#175253) mx4j-1:3.0.1-1jpp_6fc --------------------- * Wed Dec 21 2005 Jesse Keating 0:3.0.1-1jpp_6fc - rebuilt again nanoxml-0:2.2.3-3jpp_4fc ------------------------ * Wed Dec 21 2005 Jesse Keating 0:2.2.3-3jpp_4fc - rebuilt again objectweb-anttask-0:1.2-1jpp_2fc -------------------------------- * Wed Dec 21 2005 Jesse Keating 0:1.2-1jpp_2fc - rebuilt again oldkilim-0:1.1.3-2jpp_4fc ------------------------- * Wed Dec 21 2005 Jesse Keating 0:1.1.3-2jpp_4fc - rebuilt again oro-0:2.0.8-1jpp_4fc -------------------- * Wed Dec 21 2005 Jesse Keating 2.0.8-1jpp_4fc - rebuilt again p6spy-0:1.3-2jpp_4fc -------------------- * Wed Dec 21 2005 Jesse Keating 0:1.3-2jpp_4fc - rebuilt again puretls-0.9-0.b4.1jpp_3fc ------------------------- * Wed Dec 21 2005 Jesse Keating 0.9-0.b4.1jpp_2fc - rebuilt again qt-1:3.3.5-11 ------------- * Wed Dec 21 2005 Than Ngo 1:3.3.5-11 - BuildRequires on libXt-devel/xorg-x11-proto-devel readahead-1:1.1-1.20.1 ---------------------- * Wed Dec 21 2005 Karel Zak - removed double slashes in the directory names - removed or fixed the rest of X11R6 directories regexp-0:1.3-2jpp_4fc --------------------- * Wed Dec 21 2005 Jesse Keating 0:1.2-2jpp_4fc - rebuilt again rhpl-0.180-1 ------------ * Wed Dec 21 2005 Chris Lumens 0.180-1 - Deprecate rhpl.log. rhpxl-0.9-1 ----------- * Wed Dec 21 2005 Chris Lumens 0.9-1 - Don't use rhpl.log anymore. selinux-policy-2.1.6-14 ----------------------- * Wed Dec 21 2005 Dan Walsh 2.1.6-14 - Lots of fixes to make mls policy work system-config-bind-4.0.0-34_FC5 ------------------------------- * Wed Dec 21 2005 Jason Vas Dias - 4.0.0-34 - fix bug 170617: don't use pam_stack in pam configuration file system-config-netboot-0.1.36-1 ------------------------------ * Wed Dec 21 2005 Jason Vas Dias - 0.1.36-1 - fix bug 170634: don't use pam_stack in pam configuration file - fix bug 171820: add desktop.in file to POTFILES.in - use 'LC_ALL=C' for updateDiskless' 'echo y | /sbin/mke2fs ...', as pointed out by email from Kiko Albiol Colomer udev-078-2 ---------- * Wed Dec 21 2005 Bill Nottingham - 078-2 - udevstart change: allow greylisting of certain modaliases (usb, firewire) * Wed Dec 21 2005 Harald Hoyer - 078-1 - version 078 - fixed symlink to pam_console.dev vnc-4.1.1-31 ------------ * Wed Dec 21 2005 Tim Waugh 4.1.1-31 - Rebase on xorg-x11-server-1.0.0-2. werken.xpath-0:0.9.4-0.beta.9jpp_2fc ------------------------------------ * Wed Dec 21 2005 Jesse Keating 0:0.9.4-0.beta.9jpp_2fc - rebuilt again wsdl4j-0:1.5.1-1jpp_3fc ----------------------- * Mon Dec 12 2005 Jesse Keating - 0:1.5.1-1jpp_3fc - rebuilt again xalan-j2-0:2.6.0-3jpp_6fc ------------------------- * Wed Dec 21 2005 Jesse Keating 0:2.6.0-3jpp_6fc - rebuild again xen-3.0-0.20051206.fc5.1 ------------------------ * Tue Dec 06 2005 Juan Quintela - 3.0-0.20051206.fc5.1 - 20051206 version (should be 3.0.0). - Remove xen-bootloader fixes (integrated upstream). xerces-j2-0:2.6.2-6jpp_1fc -------------------------- * Wed Dec 21 2005 Jesse Keating 0:2.6.2-6jpp_1fc - rebuilt for new gcj xfig-3.2.4-17 ------------- * Wed Dec 21 2005 Than Ngo 3.2.4-17 - workaround for utf8 xjavadoc-0:1.1-1jpp_3fc ----------------------- * Wed Dec 21 2005 Jesse Keating 1.1-1jpp_2fc - rebuilt again xml-commons-0:1.0-0.b2.7jpp_4fc ------------------------------- * Wed Dec 21 2005 Jesse Keating 0:1.0-0.b2.7jpp_4fc - rebuilt again * Tue Dec 13 2005 Jesse Keating - rebuilt for new gcj * Fri Dec 09 2005 Jesse Keating - rebuilt xml-commons-resolver-0:1.1-1jpp_7fc ----------------------------------- * Wed Dec 21 2005 Jesse Keating 0:1.1-1jpp_7fc - rebuilt again xorg-x11-server-1.0.0-2 ----------------------- * Wed Dec 21 2005 Mike A. Harris 1.0.0-2 - Added xserver-1.0.0-parser-add-missing-headers-to-sdk.patch to provide the necessary libxf86config.a headers to be able to use the library. (#173084) xterm-207-10 ------------ * Wed Dec 21 2005 Jason Vas Dias - 207-10 - Fix bug 164210: tek4014 support should be enabled by default yum-2.5.0-5 ----------- * Wed Dec 21 2005 Paul Nasrat - 2.5.0-5 - Make txmbr hashable (#175975) Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.2.i686 requires /lib/modules/2.6.14-1.1775_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.2.i686 requires kernel = 0:2.6.14-1.1775_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.2.i686 requires kernel-smp = 0:2.6.14-1.1775_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.2.i686 requires /lib/modules/2.6.14-1.1775_FC5smp cman-kernel - 2.6.14.1-20051219.162641.FC5.3.i686 requires /lib/modules/2.6.14-1.1775_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.3.i686 requires kernel = 0:2.6.14-1.1775_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.3.i686 requires kernel-smp = 0:2.6.14-1.1775_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.3.i686 requires /lib/modules/2.6.14-1.1775_FC5smp dlm-kernel - 2.6.14.1-20051219.162641.FC5.2.i686 requires /lib/modules/2.6.14-1.1775_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.2.i686 requires kernel = 0:2.6.14-1.1775_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.2.i686 requires kernel-smp = 0:2.6.14-1.1775_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.2.i686 requires /lib/modules/2.6.14-1.1775_FC5smp jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 Broken deps for ia64 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) Broken deps for s390 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 systemtap - 0.5.2-2.s390 requires kernel >= 0:2.6.9-11 systemtap - 0.5.2-2.s390 requires kernel-devel Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.2.x86_64 requires /lib/modules/2.6.14-1.1775_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.2.x86_64 requires kernel = 0:2.6.14-1.1775_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.3.x86_64 requires /lib/modules/2.6.14-1.1775_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.3.x86_64 requires kernel = 0:2.6.14-1.1775_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.2.x86_64 requires /lib/modules/2.6.14-1.1775_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.2.x86_64 requires kernel = 0:2.6.14-1.1775_FC5 jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) From ggw at wolves.durham.nc.us Thu Dec 22 08:26:22 2005 From: ggw at wolves.durham.nc.us (G.Wolfe Woodbury) Date: Thu, 22 Dec 2005 03:26:22 -0500 Subject: Minor nit on new logo screen during install Message-ID: <20051222082622.GA12012@wolves.durham.nc.us> This is a minor nit-pick. I *like* the new logo screens, and I haven't even seen them all yet. In the process of doing an install of today's rawhide (2005-12-21), the text below the install progress bar is too far down and the "Release Notes" button overlaps the second line of the description by about 5-6 pixels. The text is readable, but the descenders and baseline are out of sight behind the button. --Wolfe -- G.Wolfe Woodbury `- -' RHCT U The Line Eater is a boojum! -------------- 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 Thu Dec 22 08:46:03 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Thu, 22 Dec 2005 09:46:03 +0100 Subject: Enable sqlite database backend in QT In-Reply-To: <43A8CF19.6070909@develer.com> References: <43A8CF19.6070909@develer.com> Message-ID: <43AA67CB.4050305@develer.com> Bernardo Innocenti wrote: > @@ -169,6 +178,10 @@ > BuildRequires: unixODBC-devel > %endif > > +%if %{buildsqlite} > +BuildRequires: sqlite2-devel > +%endif > + > BuildRequires: fontconfig-devel >= 2.0 > This chunk isn't actually needed because Qt builds against its in-tree copy of sqlite. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From nicolas.mailhot at laposte.net Thu Dec 22 08:53:56 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 22 Dec 2005 09:53:56 +0100 (CET) Subject: Status of docbook to pdf toolchain on Fedora? In-Reply-To: <43A9FD31.9030903@research.att.com> References: <43A99EF3.9050404@research.att.com> <20051221214325.GG16000@redhat.com> <1135207981.25397.31.camel@cassandra.boston.redhat.com> <43A9FD31.9030903@research.att.com> Message-ID: <19749.192.54.193.25.1135241636.squirrel@rousalka.dyndns.org> On Jeu 22 d?cembre 2005 02:11, John Ellson wrote: > I set "JAVA_HOME=/usr" Is that reasonable on Fedora? It says to > point it at the JDK. What JDK? On Fedora you probably want JAVA_HOME=/usr/lib/jvm -- Nicolas Mailhot From nicolas.mailhot at laposte.net Thu Dec 22 08:56:14 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 22 Dec 2005 09:56:14 +0100 (CET) Subject: Status of docbook to pdf toolchain on Fedora? In-Reply-To: <19749.192.54.193.25.1135241637.squirrel@rousalka.dyndns.org> References: <43A99EF3.9050404@research.att.com> <20051221214325.GG16000@redhat.com> <1135207981.25397.31.camel@cassandra.boston.redhat.com> <43A9FD31.9030903@research.att.com> <19749.192.54.193.25.1135241637.squirrel@rousalka.dyndns.org> Message-ID: <24545.192.54.193.25.1135241774.squirrel@rousalka.dyndns.org> On Jeu 22 d?cembre 2005 09:53, Nicolas Mailhot wrote: > > On Jeu 22 d?cembre 2005 02:11, John Ellson wrote: > >> I set "JAVA_HOME=/usr" Is that reasonable on Fedora? It says to >> point it at the JDK. What JDK? > > On Fedora you probably want JAVA_HOME=/usr/lib/jvm JAVA_HOME=/usr/lib/jvm/java or JAVA_HOME=/usr/lib/jvm/jre Most programs that want JAVA_HOME to be set require a jvm tree similar to Sun's one (not FHS compliant) so they can't use the stuff in /usr/bin Regards, -- Nicolas Mailhot From lmacken at redhat.com Thu Dec 22 09:17:57 2005 From: lmacken at redhat.com (Luke Macken) Date: Thu, 22 Dec 2005 04:17:57 -0500 Subject: Scribus in rawhide In-Reply-To: References: Message-ID: <20051222091757.GA598@tomservo.boston.redhat.com> On Tue, Dec 20, 2005 at 09:51:34AM -0800, alan wrote: | Could someone rebuild Scribus in Rawhide? It is dependant on a | non-existant version of openssl. | | Error: Missing Dependency: libssl.so.5()(64bit) is needed by package | scribus | Error: Missing Dependency: libcrypto.so.5()(64bit) is needed by package | scribus | | It has been like this for at least a week. | | Thanks! done. luke From alan at redhat.com Thu Dec 22 11:25:17 2005 From: alan at redhat.com (Alan Cox) Date: Thu, 22 Dec 2005 06:25:17 -0500 Subject: Too much time wasted installing fedora on raid1 In-Reply-To: <1135082117.3154.5.camel@localhost.localdomain> References: <20051219201653.GU1556@stingr.net> <1135026753.2947.23.camel@laptopd505.fenrus.org> <20051220085657.GW1556@stingr.net> <1135071978.2952.8.camel@laptopd505.fenrus.org> <20051220101303.GB23000@ryoko.camperquake.de> <1135073956.2952.10.camel@laptopd505.fenrus.org> <1135082117.3154.5.camel@localhost.localdomain> Message-ID: <20051222112517.GA3648@devserv.devel.redhat.com> On Tue, Dec 20, 2005 at 12:35:17PM +0000, David Woodhouse wrote: > Imagine a 'RAID resync' which only needed to resync those blocks which > the file system's journal says have been modified since the state was > last consistent... The fact Linux md doesn't currently deal with that isn't about fs/md splits its about 'nobody has written it'. High level raid stuff tends to keep dirty bitmaps and journals them so that the consistency of any stripe can be established. From dwmw2 at infradead.org Thu Dec 22 11:55:44 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Thu, 22 Dec 2005 11:55:44 +0000 Subject: Too much time wasted installing fedora on raid1 In-Reply-To: <20051222112517.GA3648@devserv.devel.redhat.com> References: <20051219201653.GU1556@stingr.net> <1135026753.2947.23.camel@laptopd505.fenrus.org> <20051220085657.GW1556@stingr.net> <1135071978.2952.8.camel@laptopd505.fenrus.org> <20051220101303.GB23000@ryoko.camperquake.de> <1135073956.2952.10.camel@laptopd505.fenrus.org> <1135082117.3154.5.camel@localhost.localdomain> <20051222112517.GA3648@devserv.devel.redhat.com> Message-ID: <1135252544.3557.19.camel@pmac.infradead.org> On Thu, 2005-12-22 at 06:25 -0500, Alan Cox wrote: > The fact Linux md doesn't currently deal with that isn't about fs/md splits > its about 'nobody has written it'. High level raid stuff tends to keep dirty > bitmaps and journals them so that the consistency of any stripe can be > established. The same information is already available in the file system's own data structures; it shouldn't be necessary for the RAID layer to do that for itself. _That_ kind of redundancy isn't what RAID is supposed to be about. But yes, there are always band-aids which can help to improve any design flaw. -- dwmw2 From rhl-devel-list at lnx.ro Thu Dec 22 12:52:58 2005 From: rhl-devel-list at lnx.ro (Dumitru Ciobarcianu) Date: Thu, 22 Dec 2005 14:52:58 +0200 Subject: Too much time wasted installing fedora on raid1 In-Reply-To: <1135252544.3557.19.camel@pmac.infradead.org> References: <20051219201653.GU1556@stingr.net> <1135026753.2947.23.camel@laptopd505.fenrus.org> <20051220085657.GW1556@stingr.net> <1135071978.2952.8.camel@laptopd505.fenrus.org> <20051220101303.GB23000@ryoko.camperquake.de> <1135073956.2952.10.camel@laptopd505.fenrus.org> <1135082117.3154.5.camel@localhost.localdomain> <20051222112517.GA3648@devserv.devel.redhat.com> <1135252544.3557.19.camel@pmac.infradead.org> Message-ID: <1135255978.6454.21.camel@localhost> ?n data de Jo, 22-12-2005 la 11:55 +0000, David Woodhouse a scris: > On Thu, 2005-12-22 at 06:25 -0500, Alan Cox wrote: > > The fact Linux md doesn't currently deal with that isn't about fs/md splits > > its about 'nobody has written it'. High level raid stuff tends to keep dirty > > bitmaps and journals them so that the consistency of any stripe can be > > established. > > The same information is already available in the file system's own data > structures; it shouldn't be necessary for the RAID layer to do that for > itself. _That_ kind of redundancy isn't what RAID is supposed to be > about. What if I use the raid device without any filesystem on it ? -- Cioby From n0dalus+redhat at gmail.com Thu Dec 22 12:57:57 2005 From: n0dalus+redhat at gmail.com (n0dalus) Date: Thu, 22 Dec 2005 23:27:57 +1030 Subject: Seperate kdelibs-devel documentation Message-ID: <6280325c0512220457u53a940a2h97f7dc79f94c7bfb@mail.gmail.com> Is it possible for /usr/share/doc/HTML/en/kdelibs-apidocs to be seperated from kdelibs-devel? On my test system (which is currently low on hard drive space), the documentation that comes with kdelibs-devel takes up over 300MB, which is almost 10% of the total size of my install (and almost 8% of the number of files on my system). This is very costly in terms of disk space for something I have not used even once. Can this be split into a kdelibs-docs package? Or is there a good reason this is so huge? Sorry if this has been asked before, I did make a good attempt to search the archives and bugzilla but was unable to find anything. n0dalus. From paul at city-fan.org Thu Dec 22 13:02:41 2005 From: paul at city-fan.org (Paul Howarth) Date: Thu, 22 Dec 2005 13:02:41 +0000 Subject: Separate kdelibs-devel documentation In-Reply-To: <6280325c0512220457u53a940a2h97f7dc79f94c7bfb@mail.gmail.com> References: <6280325c0512220457u53a940a2h97f7dc79f94c7bfb@mail.gmail.com> Message-ID: <43AAA3F1.3080608@city-fan.org> n0dalus wrote: > Is it possible for /usr/share/doc/HTML/en/kdelibs-apidocs to be > seperated from kdelibs-devel? > > On my test system (which is currently low on hard drive space), the > documentation that comes with kdelibs-devel takes up over 300MB, which > is almost 10% of the total size of my install (and almost 8% of the > number of files on my system). This is very costly in terms of disk > space for something I have not used even once. > > Can this be split into a kdelibs-docs package? Or is there a good > reason this is so huge? > > Sorry if this has been asked before, I did make a good attempt to > search the archives and bugzilla but was unable to find anything. A workaround you could try would be reinstalling the package using the --excludedocs option of rpm. However, this would seem to be a classic example of a case where a separate -docs package is justified. Paul. From christof at damian.net Thu Dec 22 13:09:38 2005 From: christof at damian.net (Christof Damian) Date: Thu, 22 Dec 2005 14:09:38 +0100 Subject: Too much time wasted installing fedora on raid1 In-Reply-To: <1135252544.3557.19.camel@pmac.infradead.org> References: <20051219201653.GU1556@stingr.net> <1135026753.2947.23.camel@laptopd505.fenrus.org> <20051220085657.GW1556@stingr.net> <1135071978.2952.8.camel@laptopd505.fenrus.org> <20051220101303.GB23000@ryoko.camperquake.de> <1135073956.2952.10.camel@laptopd505.fenrus.org> <1135082117.3154.5.camel@localhost.localdomain> <20051222112517.GA3648@devserv.devel.redhat.com> <1135252544.3557.19.camel@pmac.infradead.org> Message-ID: <20051222130938.GD2762@batman.gotham.krass.com> On Thu, 22 Dec 2005, David Woodhouse wrote: > > The same information is already available in the file system's own > data structures; it shouldn't be necessary for the RAID layer to do > that for itself. _That_ kind of redundancy isn't what RAID is > supposed to be about. > > But yes, there are always band-aids which can help to improve any > design flaw. I rather like the separation between file system and raid devices. It gives more choice and makes both components simpler. Now I can choose raid1+ext2, raid5+ext3, swap+raid0 and reiser+device. I would rather like not to loose those options. Otherwise it would be like combining "uniq" & "sort", because you could make one case work better. christof -- Christof Damian christof at damian.net From warren at togami.com Thu Dec 22 13:33:02 2005 From: warren at togami.com (Warren Togami) Date: Thu, 22 Dec 2005 08:33:02 -0500 Subject: Seperate kdelibs-devel documentation In-Reply-To: <6280325c0512220457u53a940a2h97f7dc79f94c7bfb@mail.gmail.com> References: <6280325c0512220457u53a940a2h97f7dc79f94c7bfb@mail.gmail.com> Message-ID: <43AAAB0E.2060203@togami.com> n0dalus wrote: > Is it possible for /usr/share/doc/HTML/en/kdelibs-apidocs to be > seperated from kdelibs-devel? > > On my test system (which is currently low on hard drive space), the > documentation that comes with kdelibs-devel takes up over 300MB, which > is almost 10% of the total size of my install (and almost 8% of the > number of files on my system). This is very costly in terms of disk > space for something I have not used even once. > > Can this be split into a kdelibs-docs package? Or is there a good > reason this is so huge? > > Sorry if this has been asked before, I did make a good attempt to > search the archives and bugzilla but was unable to find anything. > > n0dalus. > My personal opinion is that we should exclude it entirely because it is too big, rarely needed, and if people really want it they can easily get it from the Internet. However other people disagree and they think it is important for us to ship it. I would support the idea of a kdelibs-docs package, but it would be up to the KDE package maintainer to do it. Warren Togami wtogami at redhat.com From jspaleta at gmail.com Thu Dec 22 14:15:41 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 22 Dec 2005 09:15:41 -0500 Subject: something's uninstalling the sun jre, again In-Reply-To: <43AA4FDA.6090508@web.de> References: <1135121763.4131.50.camel@yoda.loki.me> <43A8C86A.2040308@redhat.com> <43AA4FDA.6090508@web.de> Message-ID: <604aa7910512220615o7f664f91vd0ada9f5e4ceedb9@mail.gmail.com> On 12/22/05, Marcus Hartig wrote: > Warren, which Java (Version) package do you recommend for Fedora, that I > must no edit all the symlinks in /etc/alternatives? I'm aiming to use > opencms 6.03 with tomcat, apache, firefox (java plugin) and need opencms > for a new job next year. :-) Isn't this answered in the release notes? >From the fc5t1 and fc4 release notes: Java Package Recommendations Fedora Core Whatever users are advised not to use the Java RPM provided by Sun. It contains Provides that conflict with names used in packages provided as part of Fedora Core Whatever. Because of this, Sun Java might disappear from an installed system during package upgrade operations. Fedora Core Whatever users should use either the RPM from jpackage.org or manually install the Sun Java tarball into /opt. Sun Java 1.5+ is recommended for stability purposes. -jef From alan at redhat.com Thu Dec 22 14:33:34 2005 From: alan at redhat.com (Alan Cox) Date: Thu, 22 Dec 2005 09:33:34 -0500 Subject: Too much time wasted installing fedora on raid1 In-Reply-To: <1135252544.3557.19.camel@pmac.infradead.org> References: <20051219201653.GU1556@stingr.net> <1135026753.2947.23.camel@laptopd505.fenrus.org> <20051220085657.GW1556@stingr.net> <1135071978.2952.8.camel@laptopd505.fenrus.org> <20051220101303.GB23000@ryoko.camperquake.de> <1135073956.2952.10.camel@laptopd505.fenrus.org> <1135082117.3154.5.camel@localhost.localdomain> <20051222112517.GA3648@devserv.devel.redhat.com> <1135252544.3557.19.camel@pmac.infradead.org> Message-ID: <20051222143334.GA27272@devserv.devel.redhat.com> On Thu, Dec 22, 2005 at 11:55:44AM +0000, David Woodhouse wrote: > structures; it shouldn't be necessary for the RAID layer to do that for > itself. _That_ kind of redundancy isn't what RAID is supposed to be > about. Its a neccessary part of RAID because duplicating raid functionality in every file system would be incredibly inefficient and lead to a lot of code duplication and bug. Its also neccessary because the raid functionality may not even be on the same host as the file system. > But yes, there are always band-aids which can help to improve any design > flaw. You need to learn the difference between a design flaw and pragmatic design. "Perfection is the enemy of success" From rdieter at math.unl.edu Thu Dec 22 14:49:12 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 22 Dec 2005 08:49:12 -0600 Subject: Seperate kdelibs-devel documentation In-Reply-To: <6280325c0512220457u53a940a2h97f7dc79f94c7bfb@mail.gmail.com> References: <6280325c0512220457u53a940a2h97f7dc79f94c7bfb@mail.gmail.com> Message-ID: <43AABCE8.4050603@math.unl.edu> n0dalus wrote: > Is it possible for /usr/share/doc/HTML/en/kdelibs-apidocs to be > seperated from kdelibs-devel? > > On my test system (which is currently low on hard drive space), the > documentation that comes with kdelibs-devel takes up over 300MB, That's what we do with the kde-redhat packaging. We package kdelibs-apidocs separately as noarch. -- Rex From arjan at fenrus.demon.nl Thu Dec 22 15:10:45 2005 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Thu, 22 Dec 2005 16:10:45 +0100 Subject: Seperate kdelibs-devel documentation In-Reply-To: <43AABCE8.4050603@math.unl.edu> References: <6280325c0512220457u53a940a2h97f7dc79f94c7bfb@mail.gmail.com> <43AABCE8.4050603@math.unl.edu> Message-ID: <1135264250.2940.44.camel@laptopd505.fenrus.org> On Thu, 2005-12-22 at 08:49 -0600, Rex Dieter wrote: > n0dalus wrote: > > Is it possible for /usr/share/doc/HTML/en/kdelibs-apidocs to be > > seperated from kdelibs-devel? > > > > On my test system (which is currently low on hard drive space), the > > documentation that comes with kdelibs-devel takes up over 300MB, > > That's what we do with the kde-redhat packaging. We package > kdelibs-apidocs separately as noarch. > interesting. Can you describe how the kde-redhat rpms are different from the fedora supplied ones? Is it only a different theme or are there more fundamental differences? From m.f.h at web.de Thu Dec 22 15:18:17 2005 From: m.f.h at web.de (Marcus Hartig) Date: Thu, 22 Dec 2005 16:18:17 +0100 Subject: something's uninstalling the sun jre, again In-Reply-To: <604aa7910512220615o7f664f91vd0ada9f5e4ceedb9@mail.gmail.com> References: <1135121763.4131.50.camel@yoda.loki.me> <43A8C86A.2040308@redhat.com> <43AA4FDA.6090508@web.de> <604aa7910512220615o7f664f91vd0ada9f5e4ceedb9@mail.gmail.com> Message-ID: <43AAC3B9.60208@web.de> Jeff Spaleta wrote: > Fedora Core Whatever users should use either the RPM from jpackage.org > or manually install the Sun Java tarball into /opt. Sun Java 1.5+ is > recommended for stability purposes. Oh yes, thanks...I go this way with /opt, now. Marcus From katzj at redhat.com Thu Dec 22 15:56:19 2005 From: katzj at redhat.com (Jeremy Katz) Date: Thu, 22 Dec 2005 10:56:19 -0500 Subject: Minor nit on new logo screen during install In-Reply-To: <20051222082622.GA12012@wolves.durham.nc.us> References: <20051222082622.GA12012@wolves.durham.nc.us> Message-ID: <1135266979.2340.0.camel@orodruin.boston.redhat.com> On Thu, 2005-12-22 at 03:26 -0500, G.Wolfe Woodbury wrote: > This is a minor nit-pick. > I *like* the new logo screens, and I haven't even seen them all yet. > In the process of doing an install of today's rawhide (2005-12-21), > the text below the install progress bar is too far down and the "Release > Notes" button overlaps the second line of the description by about 5-6 > pixels. The text is readable, but the descenders and baseline are out > of sight behind the button. Yeah, the header image is larger now and that throws off our all-too-careful manual padding. Will be fixed before test2 :-) Jeremy From orion at cora.nwra.com Thu Dec 22 17:13:54 2005 From: orion at cora.nwra.com (Orion Poplawski) Date: Thu, 22 Dec 2005 10:13:54 -0700 Subject: Enable sqlite database backend in QT In-Reply-To: <43AA67CB.4050305@develer.com> References: <43A8CF19.6070909@develer.com> <43AA67CB.4050305@develer.com> Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bernardo Innocenti wrote: > > This chunk isn't actually needed because Qt builds > against its in-tree copy of sqlite. > Why is it doing this? This leads to problems tracking down security fixes for sqlite. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFDqt7SORnzrtFC2/sRApYJAJ9NEK1nFPUi2StuPeab20tT1WH4VACg45IU wSLHzURJYgg7qqKEKxQGw3Y= =R5Lr -----END PGP SIGNATURE----- From rdieter at math.unl.edu Thu Dec 22 17:29:39 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 22 Dec 2005 11:29:39 -0600 Subject: kde-redhat differences In-Reply-To: <1135264250.2940.44.camel@laptopd505.fenrus.org> References: <6280325c0512220457u53a940a2h97f7dc79f94c7bfb@mail.gmail.com> <43AABCE8.4050603@math.unl.edu> <1135264250.2940.44.camel@laptopd505.fenrus.org> Message-ID: <43AAE283.5000305@math.unl.edu> Arjan van de Ven wrote: > On Thu, 2005-12-22 at 08:49 -0600, Rex Dieter wrote: >>That's what we do with the kde-redhat packaging. We package >>kdelibs-apidocs separately as noarch. > interesting. Can you describe how the kde-redhat rpms are different from > the fedora supplied ones? Is it only a different theme or are there more > fundamental differences? In general: * Compatible (ie, buildable) on/for fc3, fc4, rh9, el3, el4 (we're using mock now, yay) * Adds back most pieces redhat (purposely or not) omits * All(most?) pkgs support freedesktop.org icon spec, ie, touch top-level icon dir on install, be nice to gtk/gnome apps and run gtk-udpate-icon-cache (even though this should be, IMO, automatic, see bz * Same default (Bluecurve) theme, only slightly different defaults * Includes additional features provided by FE and livna pkgs, modularized as addon subpkgs when possible (still a bit more work to do here) * Aggressive stomping of libtool dependancy bloat * All pkgs built with standard ./configure opts: --disable-rpath \ --disable-gcc-hidden-visibility \ --enable-new-ldflags \ --disable-debug --disable-warnings \ --disable-dependancy-tracking --enable-final Specific differences (mostly off the top of my head): * qt: use qt-copy (from kde svn), includes many patches not yet accepted upstream. make $QTDIR/doc a symlink, instead of a directory containing a bunch of other symlinks * kde-i18n: provide/support all languages * kdeartwork: -icons: noarch subpkg -icons: don't rename Locolor to locolor * kdebase dbus-qt support (fc3,fc4,el4 only) enables "Start New Session" multiuser feature * kdebindings: -dcopperl: perl-DCOP bindings subpkg (because kdesdk depends on it, no need to pull in *all* of kdebindings just for this) --with-java (FIXME/TODO: make java bits a subpkg) * kdegraphics: BR: freeglut-devel (for kpovmodeler) BR: lcms-devel BR: jasper-devel * kdelibs: -apidocs: noarch subpkg BR: jasper-devel, --with-jasper BR: lua, --with-lua BR: OpenEXR-devel, --with-openexr BR: mDNSResponder, zeroconf support (sorry, not submitted to FE yet) -menus: optional XDG menus replacement of redhat-menus, providing KDE's default menus (overrides via XDG_CONFIG_DIRS env variable). /etc/profile.d/kde.(sh|csh): includes optional KDE_ env variables for tweakers: KDE_IS_PRELINKED (on), KDE_FORK_SLAVES (off), KDE_MALLOC (off), KDE_NO_IPV6 (off), GLIBC_FORCE_NEW (off), XDG_CONFIG_DIRS * kdemultimedia: -extras: extra bits enabled via FE addons (see bz #176288) -nonfree: bits enabled via livna addons * kdenetwork: BR: openslp-devel, --with-openslp * kdepim: BR: gnokii-devel, --with-gnokii BR: gpgme-devel, --with-gpg=%{_bindir}/gpg, --with-gpgsm=%{_bindir}/gpgsm (bz #136533) BR: libmal-devel (bz #172140), --with-mal From skn8700 at yahoo.co.in Thu Dec 22 17:24:53 2005 From: skn8700 at yahoo.co.in (SK Sharma) Date: Thu, 22 Dec 2005 17:24:53 +0000 (GMT) Subject: USB Flash drive testing FreeWare -reg Message-ID: <20051222172453.59032.qmail@web8509.mail.in.yahoo.com> Friends, I recently was given a 1GB USB by a friend who lives abroad....However he gave with some Photos, while some photos were rendered properly, one folder entire contents was NOT available identified with a string of "0000000000". I would appreciate if you can provide a feedback of How I get to know whether the USB drive is corrupted or otherwise & how to perform a TEST the USB from any FREE tools available online? thankyou, ShivKumar// 22,Dec- Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From skn8700 at yahoo.co.in Thu Dec 22 17:25:21 2005 From: skn8700 at yahoo.co.in (SK Sharma) Date: Thu, 22 Dec 2005 17:25:21 +0000 (GMT) Subject: USB Flash drive testing FreeWare -reg Message-ID: <20051222172521.68935.qmail@web8514.mail.in.yahoo.com> Friends, I recently was given a 1GB USB (UNbranded) by a friend who lives overseas....However he gave with some Photos, while some photos were rendered properly, one folder entire contents was NOT available identified with a string of "0000000000". I would appreciate if you can provide a feedback of How I get to know whether the USB drive is corrupted or otherwise & how to perform a TEST the USB from any FREE tools available online? thankyou, ShivKumar// 22,Dec- Send instant messages to your online friends http://in.messenger.yahoo.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From than at redhat.com Thu Dec 22 17:53:13 2005 From: than at redhat.com (Than Ngo) Date: Thu, 22 Dec 2005 18:53:13 +0100 Subject: Seperate kdelibs-devel documentation In-Reply-To: <6280325c0512220457u53a940a2h97f7dc79f94c7bfb@mail.gmail.com> References: <6280325c0512220457u53a940a2h97f7dc79f94c7bfb@mail.gmail.com> Message-ID: <43AAE809.8090509@redhat.com> n0dalus wrote: > Is it possible for /usr/share/doc/HTML/en/kdelibs-apidocs to be > seperated from kdelibs-devel? > > On my test system (which is currently low on hard drive space), the > documentation that comes with kdelibs-devel takes up over 300MB, which > is almost 10% of the total size of my install (and almost 8% of the > number of files on my system). This is very costly in terms of disk > space for something I have not used even once. > > Can this be split into a kdelibs-docs package? Or is there a good > reason this is so huge? > > Sorry if this has been asked before, I did make a good attempt to > search the archives and bugzilla but was unable to find anything. > > n0dalus. > > yes, it makes sense to split this into subpackage. It's on my todo list. Than From arjan at fenrus.demon.nl Thu Dec 22 17:58:04 2005 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Thu, 22 Dec 2005 18:58:04 +0100 Subject: kde-redhat differences In-Reply-To: <43AAE283.5000305@math.unl.edu> References: <6280325c0512220457u53a940a2h97f7dc79f94c7bfb@mail.gmail.com> <43AABCE8.4050603@math.unl.edu> <1135264250.2940.44.camel@laptopd505.fenrus.org> <43AAE283.5000305@math.unl.edu> Message-ID: <1135274285.2940.52.camel@laptopd505.fenrus.org> > * Adds back most pieces redhat (purposely or not) omits eg mp3 support ? > * Aggressive stomping of libtool dependancy bloat manual or with -Wl,--as-needed? > * All pkgs built with standard ./configure opts: > --disable-rpath \ > --disable-gcc-hidden-visibility \ why this? (the rest look to be really minor tweaks on first sight; several of which would be useful to get into the fedora rpms I guess. Minor in the sense of "not user visible") From stickster at gmail.com Thu Dec 22 18:08:18 2005 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 22 Dec 2005 13:08:18 -0500 Subject: fedora logo shows promise In-Reply-To: <43AA520F.5090509@web.de> References: <1135188074.5629.11.camel@localhost.localdomain> <43AA520F.5090509@web.de> Message-ID: <1135274898.17599.25.camel@localhost.localdomain> On Thu, 2005-12-22 at 08:13 +0100, Marcus Hartig wrote: > Paul W. Frields wrote: > > The new design is superswank, Diana's awesome! The only *minor* gripe I > > have is that the luminance of the background is too high, making text > > labels on desktop items hard to discern. This'll wow 'em from Wabash to > > Warsaw. > > If you disable the shadow text on desktop icons/labels, then it looks > very fine. That may be work for you, but not for me. In fact, it makes it worse for me. Personal tastes aside, though, making a user do this kind of defeats the whole "Just Works" idea. Bug filed (#176430). -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- 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 ph18 at cornell.edu Thu Dec 22 18:22:28 2005 From: ph18 at cornell.edu (Paul A Houle) Date: Thu, 22 Dec 2005 13:22:28 -0500 Subject: Too much time wasted installing fedora on raid1 In-Reply-To: <20051222143334.GA27272@devserv.devel.redhat.com> References: <20051219201653.GU1556@stingr.net> <1135026753.2947.23.camel@laptopd505.fenrus.org> <20051220085657.GW1556@stingr.net> <1135071978.2952.8.camel@laptopd505.fenrus.org> <20051220101303.GB23000@ryoko.camperquake.de> <1135073956.2952.10.camel@laptopd505.fenrus.org> <1135082117.3154.5.camel@localhost.localdomain> <20051222112517.GA3648@devserv.devel.redhat.com> <1135252544.3557.19.camel@pmac.infradead.org> <20051222143334.GA27272@devserv.devel.redhat.com> Message-ID: <43AAEEE4.10100@cornell.edu> Alan Cox wrote: > Its a neccessary part of RAID because duplicating raid functionality in every > file system would be incredibly inefficient and lead to a lot of code > duplication and bug. Its also neccessary because the raid functionality may > not even be on the same host as the file system. > Seen the RAID-Z system in Solaris 10? http://blogs.sun.com/roller/page/bonwick?entry=raid_z Or the Write Anywhere Filesystem used by Netfilter? http://www.netapp.com/library/tr/3002.pdf It's clear that you can get better performance and reliability by codesigning a filesystem with the block layer. I think of the difference between old-school Unix (KISS) and System 370: do you build a system that's simple and clean, or do you take the extra effort to maximize performance. Sun can afford to do this because it isn't wasting energy on maintaining 30 filesystems that almost work, but rather focusing on one that does. From rdieter at math.unl.edu Thu Dec 22 18:52:16 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 22 Dec 2005 12:52:16 -0600 Subject: Enable sqlite database backend in QT In-Reply-To: <43AA67CB.4050305@develer.com> References: <43A8CF19.6070909@develer.com> <43AA67CB.4050305@develer.com> Message-ID: <43AAF5E0.10403@math.unl.edu> Bernardo Innocenti wrote: >>+%if %{buildsqlite} >>+BuildRequires: sqlite2-devel >>+%endif >>+ >> BuildRequires: fontconfig-devel >= 2.0 > This chunk isn't actually needed because Qt builds > against its in-tree copy of sqlite. AFAICT, from looking at the code (correct me if I'm wrong)... the in-tree copy is used only if a system copy isn't found. -- Rex From rdieter at math.unl.edu Thu Dec 22 18:59:09 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 22 Dec 2005 12:59:09 -0600 Subject: kde-redhat differences In-Reply-To: <1135274285.2940.52.camel@laptopd505.fenrus.org> References: <6280325c0512220457u53a940a2h97f7dc79f94c7bfb@mail.gmail.com> <43AABCE8.4050603@math.unl.edu> <1135264250.2940.44.camel@laptopd505.fenrus.org> <43AAE283.5000305@math.unl.edu> <1135274285.2940.52.camel@laptopd505.fenrus.org> Message-ID: <43AAF77D.9000106@math.unl.edu> Arjan van de Ven wrote: >>* Adds back most pieces redhat (purposely or not) omits > eg mp3 support ? That's one, kpackage, juk, kpovmodler, a few kdegames as well. >>* Aggressive stomping of libtool dependancy bloat > manual or with -Wl,--as-needed? both. FYI, -Wl,--as-needed (and 1 or 2 other linker options) get turned on with --enable-new-ldflags. Lots of manual squashing... I've submitting many of these to bugzilla.redhat.com, just do a search for submissions from me regarding .la files. (-: >>* All pkgs built with standard ./configure opts: >> --disable-rpath \ >> --disable-gcc-hidden-visibility \ > why this? --disable-rpath is mandated by rpmlint and Fedora (Extras) packaging standards --disable-gcc-hidden-visibility, is to be on the safe side. There's still a gcc bug or 2 triggered by kde's use of -fenable-hidden-visiblity. -- Rex From rdieter at math.unl.edu Thu Dec 22 19:00:28 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 22 Dec 2005 13:00:28 -0600 Subject: fedora logo shows promise In-Reply-To: References: Message-ID: Thomas M Steenholdt wrote: > I've had a big nag against the newly proposed fedora logo for a lot of > reasons. IMHO the versions that's been on display till now have been > plain ugly. > > Luckily the latest default wallpaper somewhat changes that appearance. > There is probably still room for improvement, but Diana Fong has done a > tremendous job in making the logo look a *lot* better. If it's not too much trouble, could someone post these new logos on the web somewhere for those of us not running a development or fc5test box? -- Rex From rdieter at math.unl.edu Thu Dec 22 19:04:20 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 22 Dec 2005 13:04:20 -0600 Subject: Seperate kdelibs-devel documentation In-Reply-To: <43AAE809.8090509@redhat.com> References: <6280325c0512220457u53a940a2h97f7dc79f94c7bfb@mail.gmail.com> <43AAE809.8090509@redhat.com> Message-ID: <43AAF8B4.7070304@math.unl.edu> Than Ngo wrote: > n0dalus wrote: >> Can this be split into a kdelibs-docs package? Or is there a good >> reason this is so huge? > yes, it makes sense to split this into subpackage. It's on my todo list. You can see http://apt.kde-redhat.org/apt/kde-redhat/SPECS/kdelibs.spec for how I did it. We build it in 2 passes, one as noarch (to get kdelibs-apidocs), one as the real target arch (%{ix86}, whatever). -- Rex From rdieter at math.unl.edu Thu Dec 22 19:06:28 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 22 Dec 2005 13:06:28 -0600 Subject: kde-redhat differences In-Reply-To: <43AAF77D.9000106@math.unl.edu> References: <6280325c0512220457u53a940a2h97f7dc79f94c7bfb@mail.gmail.com> <43AABCE8.4050603@math.unl.edu> <1135264250.2940.44.camel@laptopd505.fenrus.org> <43AAE283.5000305@math.unl.edu> <1135274285.2940.52.camel@laptopd505.fenrus.org> <43AAF77D.9000106@math.unl.edu> Message-ID: <43AAF934.7030603@math.unl.edu> Rex Dieter wrote: > Arjan van de Ven wrote: >>> * All pkgs built with standard ./configure opts: >>> --disable-gcc-hidden-visibility \ >> why this? > --disable-gcc-hidden-visibility, is to be on the safe side. There's > still a gcc bug or 2 triggered by kde's use of -fenable-hidden-visiblity. To be fair, redhat/fedora's pkgs disable visibility too, just differently via patching configure. -- Rex From arjan at fenrus.demon.nl Thu Dec 22 19:03:19 2005 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Thu, 22 Dec 2005 20:03:19 +0100 Subject: kde-redhat differences In-Reply-To: <43AAF77D.9000106@math.unl.edu> References: <6280325c0512220457u53a940a2h97f7dc79f94c7bfb@mail.gmail.com> <43AABCE8.4050603@math.unl.edu> <1135264250.2940.44.camel@laptopd505.fenrus.org> <43AAE283.5000305@math.unl.edu> <1135274285.2940.52.camel@laptopd505.fenrus.org> <43AAF77D.9000106@math.unl.edu> Message-ID: <1135278200.6454.0.camel@laptopd505.fenrus.org> > --disable-gcc-hidden-visibility, is to be on the safe side. There's > still a gcc bug or 2 triggered by kde's use of -fenable-hidden-visiblity. -fenable-hidden-visibilty is the wrong solution I think (the real one is doing it right and make anonymous namespaces .so local; PR is in gcc bugzilla) From jbarnes at virtuousgeek.org Thu Dec 22 19:00:50 2005 From: jbarnes at virtuousgeek.org (Jesse Barnes) Date: Thu, 22 Dec 2005 11:00:50 -0800 Subject: kde-redhat differences In-Reply-To: <43AAE283.5000305@math.unl.edu> References: <6280325c0512220457u53a940a2h97f7dc79f94c7bfb@mail.gmail.com> <1135264250.2940.44.camel@laptopd505.fenrus.org> <43AAE283.5000305@math.unl.edu> Message-ID: <200512221100.50912.jbarnes@virtuousgeek.org> On Thursday, December 22, 2005 9:29 am, Rex Dieter wrote: > * Includes additional features provided by FE and livna pkgs, > modularized as addon subpkgs when possible (still a bit more work to > do here) Like DVD & mp3 support? Or something else? > * Aggressive stomping of libtool dependancy bloat > * All pkgs built with standard ./configure opts: > --disable-rpath \ > --disable-gcc-hidden-visibility \ > --enable-new-ldflags \ > --disable-debug --disable-warnings \ > --disable-dependancy-tracking --enable-final Why don't the regular Fedora KDE packages use these options? > * kdebase > dbus-qt support (fc3,fc4,el4 only) > enables "Start New Session" multiuser feature This seems to be available in the rawhide packages already. > * kdebindings: > -dcopperl: perl-DCOP bindings subpkg (because kdesdk depends on it, > no need to pull in *all* of kdebindings just for this) > --with-java (FIXME/TODO: make java bits a subpkg) > * kdegraphics: > BR: freeglut-devel (for kpovmodeler) Freeglut is available in the core now, isn't it? > BR: lcms-devel Should lcms go into the core? Or is kdegraphics the only package that might make use of it? > BR: jasper-devel > * kdelibs: > -apidocs: noarch subpkg > BR: jasper-devel, --with-jasper > BR: lua, --with-lua > BR: OpenEXR-devel, --with-openexr > BR: mDNSResponder, zeroconf support (sorry, not submitted to FE > yet) This would be good to get in, it would allow for easier printer discovery, right? > -menus: optional XDG menus replacement of redhat-menus, providing > KDE's default menus (overrides via XDG_CONFIG_DIRS env variable). > /etc/profile.d/kde.(sh|csh): includes optional KDE_ env variables for > tweakers: KDE_IS_PRELINKED (on), KDE_FORK_SLAVES (off), KDE_MALLOC > (off), KDE_NO_IPV6 (off), GLIBC_FORCE_NEW (off), XDG_CONFIG_DIRS * > kdemultimedia: > -extras: extra bits enabled via FE addons (see bz #176288) > -nonfree: bits enabled via livna addons > * kdenetwork: BR: openslp-devel, --with-openslp > * kdepim: > BR: gnokii-devel, --with-gnokii > BR: gpgme-devel, --with-gpg=%{_bindir}/gpg, > --with-gpgsm=%{_bindir}/gpgsm (bz #136533) > BR: libmal-devel (bz #172140), --with-mal Dunno about this stuff... Jesse From rdieter at math.unl.edu Thu Dec 22 19:22:30 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Thu, 22 Dec 2005 13:22:30 -0600 Subject: kde-redhat differences In-Reply-To: <200512221054.13068.jesse.barnes@intel.com> References: <6280325c0512220457u53a940a2h97f7dc79f94c7bfb@mail.gmail.com> <1135264250.2940.44.camel@laptopd505.fenrus.org> <43AAE283.5000305@math.unl.edu> <200512221054.13068.jesse.barnes@intel.com> Message-ID: <43AAFCF6.8040508@math.unl.edu> Jesse Barnes wrote: >>* Aggressive stomping of libtool dependancy bloat >>* All pkgs built with standard ./configure opts: >> --disable-rpath \ >> --disable-gcc-hidden-visibility \ >> --enable-new-ldflags \ >> --disable-debug --disable-warnings \ >> --disable-dependancy-tracking --enable-final > > > Why don't the regular Fedora KDE packages use these options? They all use at least some of them, but not consistently. >>* kdebase >> enables "Start New Session" multiuser feature > This seems to be available in the rawhide packages already. Great. One less thing to bugzilla about. (-; -- Rex From pemboa at gmail.com Thu Dec 22 19:39:17 2005 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 22 Dec 2005 13:39:17 -0600 Subject: kde-redhat differences In-Reply-To: <43AAFCF6.8040508@math.unl.edu> References: <6280325c0512220457u53a940a2h97f7dc79f94c7bfb@mail.gmail.com> <1135264250.2940.44.camel@laptopd505.fenrus.org> <43AAE283.5000305@math.unl.edu> <200512221054.13068.jesse.barnes@intel.com> <43AAFCF6.8040508@math.unl.edu> Message-ID: <16de708d0512221139w1e76b15elaba05ba8908b5ab2@mail.gmail.com> Out of curiousity, why is it that the kde-redhat guys are working seperate from fedora core? On 12/22/05, Rex Dieter wrote: > > Jesse Barnes wrote: > > > >>* Aggressive stomping of libtool dependancy bloat > >>* All pkgs built with standard ./configure opts: > >> --disable-rpath \ > >> --disable-gcc-hidden-visibility \ > >> --enable-new-ldflags \ > >> --disable-debug --disable-warnings \ > >> --disable-dependancy-tracking --enable-final > > > > > > Why don't the regular Fedora KDE packages use these options? > > They all use at least some of them, but not consistently. > > >>* kdebase > >> enables "Start New Session" multiuser feature > > > This seems to be available in the rawhide packages already. > > Great. One less thing to bugzilla about. (-; > > -- Rex > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From lamont at gurulabs.com Thu Dec 22 20:32:59 2005 From: lamont at gurulabs.com (Lamont R. Peterson) Date: Thu, 22 Dec 2005 13:32:59 -0700 Subject: fedora logo shows promise In-Reply-To: References: Message-ID: <200512221333.04232.lamont@gurulabs.com> On Thursday 22 December 2005 12:00pm, Rex Dieter wrote: [snip] > If it's not too much trouble, could someone post these new logos on the > web somewhere for those of us not running a development or fc5test box? > > -- Rex Yeah. What he said, please :) . -- Lamont R. Peterson Senior Instructor Guru Labs, L.C. [ http://www.GuruLabs.com/ ] -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From stickster at gmail.com Thu Dec 22 20:43:15 2005 From: stickster at gmail.com (Paul W. Frields) Date: Thu, 22 Dec 2005 15:43:15 -0500 Subject: fedora logo shows promise In-Reply-To: <200512221333.04232.lamont@gurulabs.com> References: <200512221333.04232.lamont@gurulabs.com> Message-ID: <1135284195.17599.28.camel@localhost.localdomain> On Thu, 2005-12-22 at 13:32 -0700, Lamont R. Peterson wrote: > On Thursday 22 December 2005 12:00pm, Rex Dieter wrote: > [snip] > > If it's not too much trouble, could someone post these new logos on the > > web somewhere for those of us not running a development or fc5test box? > > Yeah. What he said, please :) . http://paul.frields.org/images/new-fedora-desktop.png -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- 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 Thu Dec 22 20:48:45 2005 From: jwboyer at jdub.homelinux.org (Josh Boyer) Date: Thu, 22 Dec 2005 14:48:45 -0600 Subject: fedora logo shows promise In-Reply-To: <200512221333.04232.lamont@gurulabs.com> References: <200512221333.04232.lamont@gurulabs.com> Message-ID: <1135284525.2764.0.camel@yoda.jdub.homelinux.org> On Thu, 2005-12-22 at 13:32 -0700, Lamont R. Peterson wrote: > On Thursday 22 December 2005 12:00pm, Rex Dieter wrote: > [snip] > > If it's not too much trouble, could someone post these new logos on the > > web somewhere for those of us not running a development or fc5test box? > > > > -- Rex > > Yeah. What he said, please :) . http://jdub.homelinux.org/images/Screenshot.png josh From sundaram at redhat.com Thu Dec 22 20:50:20 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 23 Dec 2005 02:20:20 +0530 Subject: fedora logo shows promise In-Reply-To: <200512221333.04232.lamont@gurulabs.com> References: <200512221333.04232.lamont@gurulabs.com> Message-ID: <43AB118C.7040803@redhat.com> Lamont R. Peterson wrote: >On Thursday 22 December 2005 12:00pm, Rex Dieter wrote: >[snip] > > >>If it's not too much trouble, could someone post these new logos on the >>web somewhere for those of us not running a development or fc5test box? >> >>-- Rex >> >> > >Yeah. What he said, please :) . > > I have started adding these here: http://fedoraproject.org/wiki/Tours/FedoraCore5. Grub screen, Desktop, splash screen, a screencast of the screensaver, pup and any of the new visual elements for the current development tree and Fedora Core 5 can be added here. If you are interested in adding any of such details to the above wiki page go ahead. If you need any help with this see http://fedoraproject.org/wiki/WikiEditing. -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From pemboa at gmail.com Thu Dec 22 21:18:08 2005 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 22 Dec 2005 15:18:08 -0600 Subject: fedora logo shows promise In-Reply-To: <1135284525.2764.0.camel@yoda.jdub.homelinux.org> References: <200512221333.04232.lamont@gurulabs.com> <1135284525.2764.0.camel@yoda.jdub.homelinux.org> Message-ID: <16de708d0512221318u70c543b3j1493a00a88e5cc70@mail.gmail.com> Sexy screenshot On 12/22/05, Josh Boyer wrote: > > On Thu, 2005-12-22 at 13:32 -0700, Lamont R. Peterson wrote: > > On Thursday 22 December 2005 12:00pm, Rex Dieter wrote: > > [snip] > > > If it's not too much trouble, could someone post these new logos on > the > > > web somewhere for those of us not running a development or fc5test > box? > > > > > > -- Rex > > > > Yeah. What he said, please :) . > > http://jdub.homelinux.org/images/Screenshot.png > > josh > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From green at redhat.com Thu Dec 22 22:14:37 2005 From: green at redhat.com (Anthony Green) Date: Thu, 22 Dec 2005 14:14:37 -0800 Subject: something's uninstalling the sun jre, again In-Reply-To: <43AAC3B9.60208@web.de> References: <1135121763.4131.50.camel@yoda.loki.me> <43A8C86A.2040308@redhat.com> <43AA4FDA.6090508@web.de> <604aa7910512220615o7f664f91vd0ada9f5e4ceedb9@mail.gmail.com> <43AAC3B9.60208@web.de> Message-ID: <1135289678.2979.23.camel@localhost.localdomain> On Thu, 2005-12-22 at 16:18 +0100, Marcus Hartig wrote: > Jeff Spaleta wrote: > > > Fedora Core Whatever users should use either the RPM from jpackage.org > > or manually install the Sun Java tarball into /opt. Sun Java 1.5+ is > > recommended for stability purposes. > > Oh yes, thanks...I go this way with /opt, now. This is actually bogus advice that we'll be fixing in the release notes. We highly recommend _not_ installing Sun's tarball into /opt or anywhere else. Sun's raw RPMs are also bad news. See the following for how to do it right... http://fedoranews.org/mediawiki/index.php/JPackage_Java_for_FC4 AG From jspaleta at gmail.com Thu Dec 22 22:20:09 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 22 Dec 2005 17:20:09 -0500 Subject: something's uninstalling the sun jre, again In-Reply-To: <1135289678.2979.23.camel@localhost.localdomain> References: <1135121763.4131.50.camel@yoda.loki.me> <43A8C86A.2040308@redhat.com> <43AA4FDA.6090508@web.de> <604aa7910512220615o7f664f91vd0ada9f5e4ceedb9@mail.gmail.com> <43AAC3B9.60208@web.de> <1135289678.2979.23.camel@localhost.localdomain> Message-ID: <604aa7910512221420j6cb36838qeef3cbcb2d658180@mail.gmail.com> On 12/22/05, Anthony Green wrote: > See the following for how to do it right... > http://fedoranews.org/mediawiki/index.php/JPackage_Java_for_FC4 would it make sense to have instructions on doing the rpmbuild in mock for completeness? -jef From eric.tanguy at univ-nantes.fr Thu Dec 22 21:43:31 2005 From: eric.tanguy at univ-nantes.fr (Eric Tanguy) Date: Thu, 22 Dec 2005 22:43:31 +0100 Subject: KDE 3.5 Message-ID: <1135287812.3576.0.camel@bureau.maison> I would like to know why this version was pushed directly in FC-4 and not in update-testing before. This would avoid the problem with k3b!! Now we have to wait a k3b update to make it run. Thanks Eric From green at redhat.com Thu Dec 22 22:50:19 2005 From: green at redhat.com (Anthony Green) Date: Thu, 22 Dec 2005 14:50:19 -0800 Subject: something's uninstalling the sun jre, again In-Reply-To: <604aa7910512221420j6cb36838qeef3cbcb2d658180@mail.gmail.com> References: <1135121763.4131.50.camel@yoda.loki.me> <43A8C86A.2040308@redhat.com> <43AA4FDA.6090508@web.de> <604aa7910512220615o7f664f91vd0ada9f5e4ceedb9@mail.gmail.com> <43AAC3B9.60208@web.de> <1135289678.2979.23.camel@localhost.localdomain> <604aa7910512221420j6cb36838qeef3cbcb2d658180@mail.gmail.com> Message-ID: <1135291819.2979.34.camel@localhost.localdomain> On Thu, 2005-12-22 at 17:20 -0500, Jeff Spaleta wrote: > > would it make sense to have instructions on doing the rpmbuild in mock > for completeness? I don't know anything about mock, so I can't say. To be honest, I had never heard of mock before and was hoping it was something like jive or pig-latin... "You want to install Sun's java? Only fools resort to such pathetic depths! Start by downloading the wrapper source RPM from Jpackage.org. That is, if your mommy let's you. Jerk." AG From m.f.h at web.de Thu Dec 22 23:52:36 2005 From: m.f.h at web.de (Marcus Hartig) Date: Fri, 23 Dec 2005 00:52:36 +0100 Subject: fedora logo shows promise In-Reply-To: <200512221333.04232.lamont@gurulabs.com> References: <200512221333.04232.lamont@gurulabs.com> Message-ID: <43AB3C44.1070607@web.de> Lamont R. Peterson wrote: > Yeah. What he said, please :) . And another big one for Santa, because I can't sleep this night...too much coffee. ;-) http://www.marcush.de/fun/fedora-desk.png Marcus From selinux at gmail.com Fri Dec 23 00:09:42 2005 From: selinux at gmail.com (Tom London) Date: Thu, 22 Dec 2005 16:09:42 -0800 Subject: something's uninstalling the sun jre, again In-Reply-To: <1135289678.2979.23.camel@localhost.localdomain> References: <1135121763.4131.50.camel@yoda.loki.me> <43A8C86A.2040308@redhat.com> <43AA4FDA.6090508@web.de> <604aa7910512220615o7f664f91vd0ada9f5e4ceedb9@mail.gmail.com> <43AAC3B9.60208@web.de> <1135289678.2979.23.camel@localhost.localdomain> Message-ID: <4c4ba1530512221609t7007b3cayfdebfa8b1a3a05a0@mail.gmail.com> On 12/22/05, Anthony Green wrote: > On Thu, 2005-12-22 at 16:18 +0100, Marcus Hartig wrote: > > Jeff Spaleta wrote: > > > > > Fedora Core Whatever users should use either the RPM from jpackage.org > > > or manually install the Sun Java tarball into /opt. Sun Java 1.5+ is > > > recommended for stability purposes. > > > > Oh yes, thanks...I go this way with /opt, now. > > This is actually bogus advice that we'll be fixing in the release notes. > We highly recommend _not_ installing Sun's tarball into /opt or anywhere > else. Sun's raw RPMs are also bad news. > > See the following for how to do it right... > http://fedoranews.org/mediawiki/index.php/JPackage_Java_for_FC4 > > AG > Believe this needs to be updated for modular X. I get this when doing the 'yum localinstall....." --> Running transaction check --> Processing Dependency: /usr/X11R6/bin/mkfontdir for package: java-1.5.0-sun-fonts --> Finished Dependency Resolution Error: Missing Dependency: /usr/X11R6/bin/mkfontdir is needed by package java-1.5.0-sun-fonts [root at tlondon i586]# -- Tom London From tmus at tmus.dk Fri Dec 23 05:45:19 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Fri, 23 Dec 2005 06:45:19 +0100 Subject: KDE 3.5 In-Reply-To: <1135287812.3576.0.camel@bureau.maison> References: <1135287812.3576.0.camel@bureau.maison> Message-ID: Eric Tanguy wrote: > I would like to know why this version was pushed directly in FC-4 and > not in update-testing before. This would avoid the problem with k3b!! > Now we have to wait a k3b update to make it run. > Thanks > Eric > Anybody feel free to kick in and correct me if i'm wrong here, but... I believe it's been mentioned on this list somewhere before, that updates-testing is probably not getting the attention (it should?) from a wide variety of testers. My feeling is that updates-testing is *mostly* being used by people who have a bugzilla for productX and needs to test if their bug has gone away and stuff like this. This may or may not be intentional (or even true), but that's what I seem to recall from previous discussions. If it had been in updates-testing, would you have taken the time to seriously and thoroughly testing it? If yes, then it's too bad it didn't go to updates-testing, if not it wouldn't have helped much. With a limited number of people using updates-testing, some weird bug was probably going to make it through anyway. Anyway, hope this helps in some way. /Thomas From pemboa at gmail.com Fri Dec 23 05:51:33 2005 From: pemboa at gmail.com (Arthur Pemberton) Date: Thu, 22 Dec 2005 23:51:33 -0600 Subject: KDE 3.5 In-Reply-To: References: <1135287812.3576.0.camel@bureau.maison> Message-ID: <16de708d0512222151t7ed0aa2ax9358891e0573893@mail.gmail.com> Hey, i would LOVE to install and test, but I just don't have an extra/spare machine that I can chance such stuff on. On 12/22/05, Thomas M Steenholdt wrote: > > Eric Tanguy wrote: > > I would like to know why this version was pushed directly in FC-4 and > > not in update-testing before. This would avoid the problem with k3b!! > > Now we have to wait a k3b update to make it run. > > Thanks > > Eric > > > > Anybody feel free to kick in and correct me if i'm wrong here, but... > > I believe it's been mentioned on this list somewhere before, that > updates-testing is probably not getting the attention (it should?) from > a wide variety of testers. My feeling is that updates-testing is > *mostly* being used by people who have a bugzilla for productX and needs > to test if their bug has gone away and stuff like this. > This may or may not be intentional (or even true), but that's what I > seem to recall from previous discussions. > > If it had been in updates-testing, would you have taken the time to > seriously and thoroughly testing it? > > If yes, then it's too bad it didn't go to updates-testing, if not it > wouldn't have helped much. With a limited number of people using > updates-testing, some weird bug was probably going to make it through > anyway. > > Anyway, hope this helps in some way. > > /Thomas > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pemboa at gmail.com Fri Dec 23 07:19:59 2005 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 23 Dec 2005 01:19:59 -0600 Subject: Fedora in need of testers? Message-ID: <16de708d0512222319p3307eac0k476dc2b1b0a0a061@mail.gmail.com> I got the feeling from looking aroung the mailing lists that fedora is in need of testers. I am willing to use my FC4 on my Compaq Preasio 2210US to do some testing. I have a desktop with FC4 installed but it is my primary OS/machine, so I rather not play around on it. What would be required of a potential tester? -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From bernie at develer.com Fri Dec 23 07:45:55 2005 From: bernie at develer.com (Bernardo Innocenti) Date: Fri, 23 Dec 2005 08:45:55 +0100 Subject: Enable sqlite database backend in QT In-Reply-To: <43AAF5E0.10403@math.unl.edu> References: <43A8CF19.6070909@develer.com> <43AA67CB.4050305@develer.com> <43AAF5E0.10403@math.unl.edu> Message-ID: <43ABAB33.1050203@develer.com> Rex Dieter wrote: > Bernardo Innocenti wrote: > >>> +%if %{buildsqlite} >>> +BuildRequires: sqlite2-devel >>> +%endif >>> + >>> BuildRequires: fontconfig-devel >= 2.0 > >> This chunk isn't actually needed because Qt builds >> against its in-tree copy of sqlite. > > AFAICT, from looking at the code (correct me if I'm wrong)... the > in-tree copy is used only if a system copy isn't found. That's right. btw, sqlite2-devel is a Extras package. Are Core packages allowed to depend on Extras (if only through BuildRequire)? Alternatively, does the Fedora build harness support to put just the qt-sqlite package in Extras and keep the remaining packages in Core? Qt4 uses sqlite3, so this dependency problem will go away some day. -- // Bernardo Innocenti - Develer S.r.l., R&D dept. \X/ http://www.develer.com/ From lmacken at redhat.com Fri Dec 23 07:46:48 2005 From: lmacken at redhat.com (Luke Macken) Date: Fri, 23 Dec 2005 02:46:48 -0500 Subject: Fedora in need of testers? In-Reply-To: <16de708d0512222319p3307eac0k476dc2b1b0a0a061@mail.gmail.com> References: <16de708d0512222319p3307eac0k476dc2b1b0a0a061@mail.gmail.com> Message-ID: <20051223074648.GA1842@tomservo.boston.redhat.com> On Fri, Dec 23, 2005 at 01:19:59AM -0600, Arthur Pemberton wrote: | I got the feeling from looking aroung the mailing lists that fedora is in | need of testers. I am willing to use my FC4 on my Compaq Preasio 2210US to | do some testing. I have a desktop with FC4 installed but it is my primary | OS/machine, so I rather not play around on it. | | What would be required of a potential tester? Your help would be much appreciated. Every little bit counts. You can start by checking out our Testing Guide: http://fedoraproject.org/wiki/Docs/Drafts/TestingGuide luke From buildsys at redhat.com Fri Dec 23 08:19:48 2005 From: buildsys at redhat.com (Build System) Date: Fri, 23 Dec 2005 03:19:48 -0500 Subject: rawhide report: 20051223 changes Message-ID: <200512230819.jBN8JmWP009800@porkchop.devel.redhat.com> New package liboil Library of Optimized Inner Loops, CPU optimized functions Updated Packages: MAKEDEV-3.20-3 -------------- * Thu Dec 22 2005 Nalin Dahyabhai 3.20-3 - actually get the name of the file right * Thu Dec 22 2005 Nalin Dahyabhai 3.20-2 - actually include the devices.txt file which corresponds to the 2.6 kernel aqbanking-1.8.1beta-1 --------------------- aspell-12:0.60.3-3 ------------------ * Mon Dec 19 2005 Ivana Varekova 12:0.60.3-3 - fix for gcc 4.1 avahi-0.6.1-3 ------------- * Thu Dec 22 2005 Jason Vas Dias - 0.6.1-3 - move initscripts from /etc/init.d to /etc/rc.d/init.d avalon-framework-0:4.1.4-2jpp_7fc --------------------------------- * Wed Dec 21 2005 Gary Benson 0:4.1.4-2jpp_7fc - Rebuild again avalon-logkit-0:1.2-3jpp_2fc ---------------------------- * Wed Dec 21 2005 Jesse Keating 0:1.2-3jpp_2fc - bump again boost-1.33.1-2 -------------- * Thu Dec 22 2005 Jesse Keating 1.33.1-2 - rebuilt * Mon Nov 14 2005 Benjamin Kosnik 1.33.1-1 - Update to boost-1.33.1 beta. - Run testsuite, gather results. cairo-java-1.0.2-0 ------------------ * Thu Dec 22 2005 Andrw Cagney - 1.0.2-0 Adam Jocksch - import cairo-java-1.0.2.tar.gz. * Wed Dec 21 2005 Jesse Keating - 1.0.0-5 - build on s390x again. carol-0:1.8.9.3-1jpp_8fc ------------------------ * Wed Dec 21 2005 Jesse Keating 0:1.8.9.3-1jpp_8fc - rebuilt again cscope-15.5-13 -------------- * Fri Dec 16 2005 Jesse Keating - rebuild on new gcc dlm-1.0.0-9.FC5 --------------- * Thu Dec 22 2005 Jesse Keating - rebuilt again - don't build on ppc ppc64 since the dlm-kernel isnt built there either. * Fri Dec 09 2005 Jesse Keating - rebuilt * Tue May 17 2005 Chris Feist - Requires dlm-kernel-modules. dlm-kernel-2.6.14.1-20051219.162641.FC5.3 ----------------------------------------- * Wed Dec 21 2005 Jesse Keating - rebuilt * Mon Dec 19 2005 Chris Feist - Updated upstream sources. * Fri Dec 09 2005 Jesse Keating - rebuilt eclipse-1:3.1.1-1jpp_13fc ------------------------- * Wed Dec 21 2005 Andrew Overholt 3.1.1-1jpp_13fc - Rebuild with new gcc (gcc#25121). ethereal-0.10.14-0.pre1 ----------------------- * Thu Dec 22 2005 Radek Vokal 0.10.14-0.pre1 - 0.10.14 prerelease, fix for conflict with error.h frysk-0.0.1.2005.12.14.15.12-0.FC4.1 ------------------------------------ * Thu Dec 22 2005 Andrew Cagney 0.0.1.2005.12.14.15.12-0.FC4.1 - Import frysk-0.0.1.2005.12.14.15.12 rpm. - Drop build dependency java-1.4.2-gcj-compat-devel - Apply Patch003, frysk-makefileam.patch. gawk-3.1.5-5 ------------ * Thu Dec 22 2005 Karel Zak 3.1.5-5 - fix "gawk -v BINMODE=1" (patch by Aharon Robbins) - fix conversion from large number to string (patch by Aharon Robbins) geronimo-specs-0:1.0-0.M2.2jpp_5fc ---------------------------------- * Wed Dec 21 2005 Jesse Keating 0:1.0-0.M2.2jpp_5fc - rebuilt again glib-java-0.2.2-1 ----------------- * Thu Dec 22 2005 Adam Jocksch - bumped version to 0.2.2, updated tarball. gnucash-1.8.12-1 ---------------- * Thu Dec 22 2005 Bill Nottingham 1.8.12-1 - update to 1.8.12 * Fri Dec 09 2005 Jesse Keating - rebuilt gpm-1.20.1-72 ------------- * Thu Dec 22 2005 Jesse Keating 1.20.1-72 - rebuilt again * Fri Dec 09 2005 Jesse Keating - rebuilt - added autoconf as a BuildReq gwenhywfar-1.99.2-1 ------------------- * Thu Dec 22 2005 Bill Nottingham 1.99.2-1 - update to 1.99.2 - use the pkgconfig file, not gwenhywfar-config jakarta-commons-beanutils-0:1.7.0-2jpp_4fc ------------------------------------------ * Wed Dec 21 2005 Jesse Keating - 0:1.7.0-2jpp_4fc - rebuilt again jakarta-commons-cli-0:1.0-6jpp_3fc ---------------------------------- * Wed Dec 21 2005 Jesse Keating - 0:1.0-6jpp_3fc - rebuilt again jakarta-commons-digester-0:1.6-2jpp_7fc --------------------------------------- * Wed Dec 21 2005 Jesse Keating - 0:1.6-2jpp_7fc - rebuilt again jakarta-commons-discovery-1:0.3-1jpp_3fc ---------------------------------------- * Wed Dec 21 2005 Jesse Keating -1:1:0.3-1jpp_3fc - rebuilt again jakarta-commons-el-0:1.0-4jpp_4fc --------------------------------- * Wed Dec 21 2005 Jesse Keating - 0:1.0-4jpp_4fc - rebuilt again jakarta-commons-fileupload-1:1.0-3jpp_4fc ----------------------------------------- * Wed Dec 21 2005 Jesse Keating - 1:1.0-3jpp_3fc - rebuilt again jakarta-commons-httpclient-1:3.0-0.rc2.0jpp_3fc ----------------------------------------------- * Wed Dec 21 2005 Jesse Keating - 1:3.0-0.rc2.0jpp_3fc - rebuilt again jakarta-commons-logging-0:1.0.4-2jpp_8fc ---------------------------------------- * Wed Dec 21 2005 Jesse Keating - 0:1.0.4-2jpp_8fc - rebuilt again jakarta-commons-modeler-0:1.1-4jpp_4fc -------------------------------------- * Wed Dec 21 2005 Jesse Keating - 0:1.1-4jpp_4fc - rebuilt again jakarta-commons-validator-0:1.1.3-1jpp_4fc ------------------------------------------ * Wed Dec 21 2005 Jesse Keating - 0:1.1.3-1jpp_4fc - rebuilt again jessie-0:1.0.0-11 ----------------- * Thu Dec 22 2005 Jesse Keating 0:1.0.0-11 - Bump for gcc/gcj jgroups-0:2.2.6-1jpp_3fc ------------------------ * Wed Dec 21 2005 Jesse Keating 0:2.2.6-1jpp_3fc - rebuilt again jonathan-core-0:4.1-1jpp_6fc ---------------------------- * Wed Dec 21 2005 Jesse Keating 0:4.1-1jpp_6fc - rebuilt again jonathan-jeremie-0:4.2-1jpp_6fc ------------------------------- * Wed Dec 21 2005 Jesse Keating 0:4.2-1jpp_6fc - rebuilt done jonathan-rmi-3.1-6 ------------------ * Wed Dec 21 2005 Jesse Keating 3.1-6 - rebuilt again jotm-0:2.0.5-1jpp_5fc --------------------- * Wed Dec 21 2005 Jesse Keating 0:2.0.5-1jpp_5fc - rebuilt again kernel-2.6.14-1.1783_FC5 ------------------------ * Thu Dec 22 2005 Dave Jones - 2.6.15-rc6-git3 * Wed Dec 21 2005 Dave Jones - 2.6.15-rc6-git2 libavc1394-0.5.1-2 ------------------ * Thu Dec 22 2005 Warren Togami 0.5.1-2 - remove .a and .la (#172641) - GPL -> LGPL (#165908) libgconf-java-2.12.1-2 ---------------------- * Wed Dec 21 2005 Jesse Keating - 2.12.1-2 - rebuilt again libglade-java-2.12.1-3 ---------------------- * Wed Dec 21 2005 Jesse Keating - 2.12.1-3 - rebuilt again libgnome-java-2.12.1-3 ---------------------- * Wed Dec 21 2005 Jesse Keating - 2.12.1-2 - rebuilt again * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj libgtk-java-2.8.2-0 ------------------- * Thu Dec 22 2005 Andrw Cagney - 2.8.2-0 Adam Jocksch - import libgtk-java-2.8.2.tar.gz * Wed Dec 21 2005 Jesse Keating - 2.8.1-3 - rebuilt again libofx-0.8.0-1 -------------- * Tue Dec 20 2005 Bill Nottingham 0.8.0-1 - update to 0.8.0 libvte-java-0.11.11-7 --------------------- medor-0:1.4.4-1jpp_3fc ---------------------- * Wed Dec 21 2005 Jesse Keating 0:1.4.4-1jpp_3fc - rebuilt medor-expression-0:1.4.2-1jpp_3fc --------------------------------- * Wed Dec 21 2005 Jesse Keating 0:1.4.2-1jpp_3fc - rebuilt again mockobjects-0:0.09-12jpp_4fc ---------------------------- * Wed Dec 21 2005 Jesse Keating 0:09-11jpp_4fc - rebuilt again monolog-0:1.8.6-1jpp_11fc ------------------------- * Wed Dec 21 2005 Jesse Keating 0:1.8.6-1jpp_11fc - rebuilt again objectweb-deploysched-0:0.2-1jpp_3fc ------------------------------------ * Wed Dec 21 2005 Jesse Keating 0:0.2-1jpp_3fc - rebuilt again openoffice.org-1:2.0.1.1-2.2 ---------------------------- * Wed Dec 21 2005 Caolan McNamara - 1:2.0.1.1-2 - add openoffice.org-2.0.1.oooXXXXX.vcl.animatedtheme.patch for animated theme problem oprofile-0.9.1-7 ---------------- * Thu Dec 22 2005 Jesse Keating - rebuilt pm-utils-0.08-1 --------------- * Thu Dec 22 2005 Peter Jones - 0.08-1 - Fix scripts for new pciutils policycoreutils-1.29.2-6 ------------------------ * Thu Dec 22 2005 Dan Walsh 1.29.2-6 - Turn off try catch block to debug anaconda failure rhpl-0.181-1 ------------ * Thu Dec 22 2005 Jeremy Katz - 0.181-1 - Clean up spacing and use current widgets for exception dialog - add serbian keyboard models (#175611) selinux-policy-2.1.6-16 ----------------------- * Thu Dec 22 2005 Dan Walsh 2.1.6-16 - Fix hostname in targeted policy * Wed Dec 21 2005 Dan Walsh 2.1.6-15 - Fix passwd command on mls setools-2.2-4.1 --------------- * Fri Dec 16 2005 Jesse Keating - rebuilt for new gcj * Wed Dec 14 2005 Dan Walsh 2.2-4 - Fix dessktop files - Apply fixes from bkyoung * Fri Dec 09 2005 Jesse Keating - rebuilt struts-0:1.2.4-2jpp_5fc ----------------------- * Wed Dec 21 2005 Jesse Keating - 0:1.2.4-2jpp_5fc - rebuilt again synaptics-0:0.14.4-4.1 ---------------------- * Fri Dec 09 2005 Jesse Keating - rebuilt sysreport-1.4.2-7 ----------------- * Thu Dec 22 2005 Jesse Keating 1.4.2-7 - rebuilt sysstat-6.0.1-3.1 ----------------- * Fri Dec 09 2005 Jesse Keating - rebuilt tomcat5-0:5.0.30-8jpp_7fc ------------------------- * Wed Dec 21 2005 Jesse Keating 0:5.0.30-8jpp_7fc - rebuilt again unzip-5.52-1 ------------ * Thu Dec 22 2005 Ivana Varekova 5.52-1 - update to 5.52 velocity-0:1.4-3jpp_3fc ----------------------- * Wed Dec 21 2005 Jesse Keating - 0:1.4-3jpp_3fc - rebuilt again xdoclet-0:1.2.2-2jpp_4fc ------------------------ * Wed Dec 21 2005 Jesse Keating - 0:1.2.2-2jpp_4fc - rebuilt again xen-3.0-0.20051206.fc5.2 ------------------------ * Thu Dec 22 2005 Jesse Keating - 3.0-0.20051206.fc5.2 - rebuilt xorg-x11-server-1.0.0-3 ----------------------- * Thu Dec 22 2005 Mike A. Harris 1.0.0-3 - Added "Provides: libxf86config-devel = 1.0.0-3" to sdk package. xsri-1:2.1.0-9.1 ---------------- * Fri Dec 09 2005 Jesse Keating - rebuilt Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.2.i686 requires /lib/modules/2.6.14-1.1775_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.2.i686 requires kernel = 0:2.6.14-1.1775_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.2.i686 requires kernel-smp = 0:2.6.14-1.1775_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.2.i686 requires /lib/modules/2.6.14-1.1775_FC5smp aqhbci - 1.0.2beta-2.1.i386 requires libgwenhywfar.so.17 aqhbci-devel - 1.0.2beta-2.1.i386 requires libgwenhywfar.so.17 cman-kernel - 2.6.14.1-20051219.162641.FC5.3.i686 requires /lib/modules/2.6.14-1.1775_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.3.i686 requires kernel = 0:2.6.14-1.1775_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.3.i686 requires kernel-smp = 0:2.6.14-1.1775_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.3.i686 requires /lib/modules/2.6.14-1.1775_FC5smp gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.4.i686 requires /lib/modules/2.6.14-1.1777_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.4.i686 requires kernel = 0:2.6.14-1.1777_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.4.i686 requires /lib/modules/2.6.14-1.1777_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.4.i686 requires kernel-smp = 0:2.6.14-1.1777_FC5 jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 Broken deps for ia64 ---------------------------------------------------------- aqhbci - 1.0.2beta-2.1.ia64 requires libgwenhywfar.so.17()(64bit) aqhbci-devel - 1.0.2beta-2.1.ia64 requires libgwenhywfar.so.17()(64bit) jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- aqhbci - 1.0.2beta-2.1.ppc requires libgwenhywfar.so.17 aqhbci-devel - 1.0.2beta-2.1.ppc requires libgwenhywfar.so.17 cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 Broken deps for ppc64 ---------------------------------------------------------- aqhbci - 1.0.2beta-2.1.ppc64 requires libgwenhywfar.so.17()(64bit) aqhbci-devel - 1.0.2beta-2.1.ppc64 requires libgwenhywfar.so.17()(64bit) cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) Broken deps for s390 ---------------------------------------------------------- aqhbci - 1.0.2beta-2.1.s390 requires libgwenhywfar.so.17 aqhbci-devel - 1.0.2beta-2.1.s390 requires libgwenhywfar.so.17 jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 systemtap - 0.5.2-2.s390 requires kernel >= 0:2.6.9-11 systemtap - 0.5.2-2.s390 requires kernel-devel Broken deps for s390x ---------------------------------------------------------- aqhbci - 1.0.2beta-2.1.s390x requires libgwenhywfar.so.17()(64bit) aqhbci-devel - 1.0.2beta-2.1.s390x requires libgwenhywfar.so.17()(64bit) jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) systemtap - 0.5.2-2.s390x requires kernel >= 0:2.6.9-11 systemtap - 0.5.2-2.s390x requires kernel-devel Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.2.x86_64 requires /lib/modules/2.6.14-1.1775_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.2.x86_64 requires kernel = 0:2.6.14-1.1775_FC5 aqhbci - 1.0.2beta-2.1.x86_64 requires libgwenhywfar.so.17()(64bit) aqhbci-devel - 1.0.2beta-2.1.x86_64 requires libgwenhywfar.so.17()(64bit) cman-kernel - 2.6.14.1-20051219.162641.FC5.3.x86_64 requires /lib/modules/2.6.14-1.1775_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.3.x86_64 requires kernel = 0:2.6.14-1.1775_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.4.x86_64 requires /lib/modules/2.6.14-1.1777_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.4.x86_64 requires kernel = 0:2.6.14-1.1777_FC5 jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) From pemboa at gmail.com Fri Dec 23 08:30:30 2005 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 23 Dec 2005 02:30:30 -0600 Subject: Fedora in need of testers? In-Reply-To: <20051223074648.GA1842@tomservo.boston.redhat.com> References: <16de708d0512222319p3307eac0k476dc2b1b0a0a061@mail.gmail.com> <20051223074648.GA1842@tomservo.boston.redhat.com> Message-ID: <16de708d0512230030h50bb24ddk7b107fe92eb6b85@mail.gmail.com> On 12/23/05, Luke Macken wrote: > > On Fri, Dec 23, 2005 at 01:19:59AM -0600, Arthur Pemberton wrote: > | I got the feeling from looking aroung the mailing lists that fedora is > in > | need of testers. I am willing to use my FC4 on my Compaq Preasio 2210US > to > | do some testing. I have a desktop with FC4 installed but it is my > primary > | OS/machine, so I rather not play around on it. > | > | What would be required of a potential tester? > > Your help would be much appreciated. Every little bit counts. > > You can start by checking out our Testing Guide: > http://fedoraproject.org/wiki/Docs/Drafts/TestingGuide > > luke Thanks for the link, I am on my way there now . Totally of topic, but why are good Fedora tutorials/howtos often in */draft/* ? -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pemboa at gmail.com Fri Dec 23 08:41:01 2005 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 23 Dec 2005 02:41:01 -0600 Subject: Fedora in need of testers? In-Reply-To: <20051223074648.GA1842@tomservo.boston.redhat.com> References: <16de708d0512222319p3307eac0k476dc2b1b0a0a061@mail.gmail.com> <20051223074648.GA1842@tomservo.boston.redhat.com> Message-ID: <16de708d0512230041q30d6f250qbf54eb0fcce08bcc@mail.gmail.com> Testing seems as simple as enabling the updates-testing repo. But I have one queston: i need the livna repos for my ndiswrapper, is it better to stick with the regular livna repo, or use livna-testing? Thank you. -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivazquez at ivazquez.net Fri Dec 23 08:45:00 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 23 Dec 2005 03:45:00 -0500 Subject: Fedora in need of testers? In-Reply-To: <16de708d0512230041q30d6f250qbf54eb0fcce08bcc@mail.gmail.com> References: <16de708d0512222319p3307eac0k476dc2b1b0a0a061@mail.gmail.com> <20051223074648.GA1842@tomservo.boston.redhat.com> <16de708d0512230041q30d6f250qbf54eb0fcce08bcc@mail.gmail.com> Message-ID: <1135327500.1969.9.camel@ignacio.lan> On Fri, 2005-12-23 at 02:41 -0600, Arthur Pemberton wrote: > Testing seems as simple as enabling the updates-testing repo. But I > have one queston: i need the livna repos for my ndiswrapper, is it > better to stick with the regular livna repo, or use livna-testing? That would be a question for the livna mailing list. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 Dec 23 08:47:38 2005 From: pemboa at gmail.com (Arthur Pemberton) Date: Fri, 23 Dec 2005 02:47:38 -0600 Subject: Fedora in need of testers? In-Reply-To: <1135327500.1969.9.camel@ignacio.lan> References: <16de708d0512222319p3307eac0k476dc2b1b0a0a061@mail.gmail.com> <20051223074648.GA1842@tomservo.boston.redhat.com> <16de708d0512230041q30d6f250qbf54eb0fcce08bcc@mail.gmail.com> <1135327500.1969.9.camel@ignacio.lan> Message-ID: <16de708d0512230047x72ea57e3g99bcef733fdb6f3b@mail.gmail.com> On 12/23/05, Ignacio Vazquez-Abrams wrote: > > On Fri, 2005-12-23 at 02:41 -0600, Arthur Pemberton wrote: > > Testing seems as simple as enabling the updates-testing repo. But I > > have one queston: i need the livna repos for my ndiswrapper, is it > > better to stick with the regular livna repo, or use livna-testing? > > That would be a question for the livna mailing list. Fair enough. -- As a boy I jumped through Windows, as a man I play with Penguins. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at redhat.com Fri Dec 23 09:06:03 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 23 Dec 2005 14:36:03 +0530 Subject: Fedora in need of testers? In-Reply-To: <16de708d0512230030h50bb24ddk7b107fe92eb6b85@mail.gmail.com> References: <16de708d0512222319p3307eac0k476dc2b1b0a0a061@mail.gmail.com> <20051223074648.GA1842@tomservo.boston.redhat.com> <16de708d0512230030h50bb24ddk7b107fe92eb6b85@mail.gmail.com> Message-ID: <43ABBDFB.50501@redhat.com> Hi > I got the feeling from looking aroung the mailing lists that > fedora is in need of testers > Yes. Very much so. > You can start by checking out our Testing Guide: > http://fedoraproject.org/wiki/Docs/Drafts/TestingGuide > > luke > > > Thanks for the link, I am on my way there now . > Totally of topic, but why are good Fedora tutorials/howtos often in > */draft/* ? It is in the draft section because it is work in progress. I have been adding content whenever I can but its nowhere near complete yet. -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From rdieter at math.unl.edu Fri Dec 23 09:14:56 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Fri, 23 Dec 2005 03:14:56 -0600 Subject: Enable sqlite database backend in QT In-Reply-To: <43ABAB33.1050203@develer.com> References: <43A8CF19.6070909@develer.com> <43AA67CB.4050305@develer.com> <43AAF5E0.10403@math.unl.edu> <43ABAB33.1050203@develer.com> Message-ID: <43ABC010.5010005@math.unl.edu> Bernardo Innocenti wrote: > btw, sqlite2-devel is a Extras package. Are Core packages > allowed to depend on Extras (if only through BuildRequire)? No. > Alternatively, does the Fedora build harness support to > put just the qt-sqlite package in Extras and keep the > remaining packages in Core? kinda, building/including qt-sqlite (only) in Extras is doable. -- Rex From giallu at gmail.com Fri Dec 23 12:19:02 2005 From: giallu at gmail.com (Gianluca Sforna) Date: Fri, 23 Dec 2005 13:19:02 +0100 Subject: Royalty free gstreamer plug-in Message-ID: Hi all, is this announce from Fluendo referenced here: http://www.osnews.com/story.php?news_id=13078 already being discussed at Fedora Legal? It would be really nice to finally have mp3 support OUTB in Fedora. Cheers and Happy Christmas Gianluca From nicu_fedora at nicubunu.ro Fri Dec 23 12:36:53 2005 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Fri, 23 Dec 2005 14:36:53 +0200 Subject: Royalty free gstreamer plug-in In-Reply-To: References: Message-ID: <43ABEF65.30707@nicubunu.ro> Gianluca Sforna wrote: > Hi all, > is this announce from Fluendo referenced here: > http://www.osnews.com/story.php?news_id=13078 > already being discussed at Fedora Legal? > > It would be really nice to finally have mp3 support OUTB in Fedora. If my understanding is correct, this does NOT means mp3 support "out of the box" in Fedora. It appears Fluendo got redistribution rights for binaries, not for source code - the relevant passage is "If you are living in a country where the mp3 patents don't apply you can of course use the source code". So, again, if I understood correctly, Fedora will not include this plugin (because the distribution of sources is still covered by patents) but will be free to link to a page hosting the binaries. That or Fedora will go to the darkside and include binaries and no sources. -- nicu my hats collection: http://fedora.nicubunu.ro/hats/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From sundaram at redhat.com Fri Dec 23 12:41:31 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 23 Dec 2005 18:11:31 +0530 Subject: Royalty free gstreamer plug-in In-Reply-To: References: Message-ID: <43ABF07B.6060101@redhat.com> Gianluca Sforna wrote: >Hi all, >is this announce from Fluendo referenced here: >http://www.osnews.com/story.php?news_id=13078 >already being discussed at Fedora Legal? > >It would be really nice to finally have mp3 support OUTB in Fedora. > > Thats what I thought too initially but unfortunately it doesnt change the Free software situation even a tiny bit and consequently Fedora probably wont ship this plugin. see http://www.fluendo.com/resources/fluendo_mp3.php. "If you are living in a country where the mp3 patents don't apply you can of course use the source code provided by Fluendo (or anyone else) to get legal mp3 support onto your Unix/GNU/Linux desktop." If you want mp3 support in a region where software patents are enforced you could use any recent version of RealPlayer or you can buy a proprietary plugin from Fluendo and all your gstreamer enabled application would potentially work seamlessly. Since gstreamer is sort of the Free desktop standard with GNOME and increasingly KDE and many other applications using it, this might be good news for them. Disclaimer: I am not a lawyer and all opinions expressed by me have so far are my own. -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From nicu_fedora at nicubunu.ro Fri Dec 23 13:09:24 2005 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Fri, 23 Dec 2005 15:09:24 +0200 Subject: Royalty free gstreamer plug-in In-Reply-To: <43ABF07B.6060101@redhat.com> References: <43ABF07B.6060101@redhat.com> Message-ID: <43ABF704.4070109@nicubunu.ro> Rahul Sundaram wrote: > If you want mp3 support in a region where software patents are enforced > you could use any recent version of RealPlayer or you can buy a > proprietary plugin from Fluendo and all your gstreamer enabled > application would potentially work seamlessly. Since gstreamer is sort > of the Free desktop standard with GNOME and increasingly KDE and many > other applications using it, this might be good news for them. > > Disclaimer: I am not a lawyer and all opinions expressed by me have so > far are my own. On the positive side, I think Fedora is allowed now to write in FAQ or release notes: "to play mp3 files, go to this specific Fluendo page, click and install the rpm" -- nicu my hats collection: http://fedora.nicubunu.ro/hats/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From sundaram at redhat.com Fri Dec 23 13:11:43 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 23 Dec 2005 18:41:43 +0530 Subject: Royalty free gstreamer plug-in In-Reply-To: <43ABF704.4070109@nicubunu.ro> References: <43ABF07B.6060101@redhat.com> <43ABF704.4070109@nicubunu.ro> Message-ID: <43ABF78F.7000506@redhat.com> Hi > > On the positive side, I think Fedora is allowed now to write in FAQ or > release notes: "to play mp3 files, go to this specific Fluendo page, > click and install the rpm" > We could have done that with RealPlayer long before. We dont do that since we dont support proprietary formats. If you want a Free software platform be prepared to support and use a Free and superior format like Ogg. Thats my take on it. -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From gajownik at fedora.pl Fri Dec 23 13:19:08 2005 From: gajownik at fedora.pl (Dawid Gajownik) Date: Fri, 23 Dec 2005 14:19:08 +0100 Subject: KDE 3.5 In-Reply-To: References: <1135287812.3576.0.camel@bureau.maison> Message-ID: <43ABF94C.8070109@fedora.pl> Dnia 12/23/2005 06:45 AM, U?ytkownik Thomas M Steenholdt napisa?: > I believe it's been mentioned on this list somewhere before, that > updates-testing is probably not getting the attention (it should?) from > a wide variety of testers. My feeling is that updates-testing is > *mostly* being used by people who have a bugzilla for productX and needs > to test if their bug has gone away and stuff like this. I'm using updates-testing all the time on my box :P > If it had been in updates-testing, would you have taken the time to > seriously and thoroughly testing it? Some bugs could have been fixed before pushing packages to updates-released (for instance #176045). > If yes, then it's too bad it didn't go to updates-testing, if not it > wouldn't have helped much. KDE 3.5 update made a really BAD impression on users (at least on forum.fedora.pl) -- problems with system update, gaim crash, k3b crash and so on. Some of them start to believe that Fedora is not stable or they stop to update systems :/ Such situations should be avoided in the future because they ruin good Fedora's reputation. Loosing users is the worst thing that can happen... -- ^_* From sundaram at redhat.com Fri Dec 23 13:25:33 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 23 Dec 2005 18:55:33 +0530 Subject: KDE 3.5 In-Reply-To: <43ABF94C.8070109@fedora.pl> References: <1135287812.3576.0.camel@bureau.maison> <43ABF94C.8070109@fedora.pl> Message-ID: <43ABFACD.1030906@redhat.com> Hi > > Some bugs could have been fixed before pushing packages to > updates-released (for instance #176045). Maybe. If you are trying out updates-testing, in addition to filing bug reports you can post your feedback to the fedora-test list for peer views. Bugzilla is sort of this direct reporter <-> developer feedback which can sometimes go into a blackhole. If you dont get feedback on bugzilla, dont hesitate to followup on the fedora-test list as appropriate. If you think there are blocker bugs let us know. We asked the community to report bugs when they see problems and many of them dutifully do so but unfortunately many of them are duplicates, dont contain required information, invalid bugs etc. So we need more of the community to be on *receiving* end now and those dont have to be developers or requires any coding knowledge at all in many cases. We dont have much people going through the bugs and triaging them and getting back feedback to users. Red Hat is in the process of hiring a full time Fedora triager among other things to improve the QA process but meanwhile rest of the community could organize and do regular bug days and triaging. We started out this effort recently at http://fedorproject.org/wiki/BugZappers. Not much traction yet after the initial efforts though. > KDE 3.5 update made a really BAD impression on users (at least on > forum.fedora.pl) -- problems with system update, gaim crash, k3b crash > and so on. Some of them start to believe that Fedora is not stable or > they stop to update systems :/ > > Such situations should be avoided in the future because they ruin good > Fedora's reputation. Loosing users is the worst thing that can happen... Fully agreed on that but like I said it requires more community participation now. No magic bullers there. -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From tmus at tmus.dk Fri Dec 23 13:37:57 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Fri, 23 Dec 2005 14:37:57 +0100 Subject: Royalty free gstreamer plug-in In-Reply-To: <43ABF78F.7000506@redhat.com> References: <43ABF07B.6060101@redhat.com> <43ABF704.4070109@nicubunu.ro> <43ABF78F.7000506@redhat.com> Message-ID: Rahul Sundaram wrote: > We could have done that with RealPlayer long before. We dont do that > since we dont support proprietary formats. If you want a Free software > platform be prepared to support and use a Free and superior format like > Ogg. Thats my take on it. > That's how i view it too... As an added benefit, IMHO, ogg is a far better format for lots of reasons! Users should "learn" to use it or simply install an mp3 plugin from somewhere. I think it's kinda nice that users are "exposed" to the open formats in this way. /Thomas From praszyk at redhat.com Fri Dec 23 13:41:42 2005 From: praszyk at redhat.com (Petr Raszyk) Date: Fri, 23 Dec 2005 14:41:42 +0100 Subject: ncurses-5.5 Message-ID: <1135345302.31243.18.camel@echo.redhat.usu> The ncurses package has been upgraded to the latest upstream version 5.5. Tested in FEDORA CORE 4 (less, vim, emacs, screen, ... (without app-rebuild)). dickey at invisible-island.net: This release is designed to be upward compatible from ncurses 5.0 through 5.4; very few applications will require recompilation, depending on the platform. These are the highlights from the change-log since ncurses 5.4 release. Interface changes: * terminfo installs "xterm-new" as "xterm" entry rather than "xterm-old" (aka xterm-r6). * terminfo data is installed using the tic -x option (few systems still use ncurses 4.2). * modify C++ binding to work with newer C++ compilers by providing initializers and using modern casts. Old-style header names are still used in this release to allow compiling with not-so-old compilers. * modify parameter type in c++ binding for insch() and mvwinsch() to be consistent with underlying ncurses library (was char, is chtype). * change NCursesWindow::err_handler() to a virtual function. * form and menu libraries now work with wide-character data. Applications which bypassed the form library and manipulated the FIELD.buf data directly will not work properly with libformw, since that no longer points to an array of char. The set_field_buffer() and field_buffer() functions translate to/from the actual field data. * add symbol to curses.h which can be used to suppress include of stdbool.h, e.g., #define NCURSES_ENABLE_STDBOOL_H 0 #include * change SP->_current_attr to a pointer, adjust ifdef's to ensure that libtinfo.so and libtinfow.so have the same ABI. The reason for this is that the corresponding data which belongs to the upper-level ncurses library has a different size in each model. * winnstr() now returns multibyte character strings for the wide-character configuration. * assume_default_colors() no longer requires that use_default_colors() be called first. * data_ahead() now works with wide-characters. * slk_set() and slk_wset() now accept and store multibyte or multicolumn characters. * start_color() now returns OK if colors have already been started. start_color() also returns ERR if it cannot allocate memory. * pair_content() now returns -1 for consistency with init_pair() if it corresponds to the default-color. * unctrl() now returns null if its parameter does not correspond to an unsigned char. From sundaram at redhat.com Fri Dec 23 13:44:22 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 23 Dec 2005 19:14:22 +0530 Subject: KDE 3.5 In-Reply-To: <43ABFACD.1030906@redhat.com> References: <1135287812.3576.0.camel@bureau.maison> <43ABF94C.8070109@fedora.pl> <43ABFACD.1030906@redhat.com> Message-ID: <43ABFF36.5000602@redhat.com> Hi > . We started out this effort recently at > http://fedorproject.org/wiki/BugZappers. Not much traction yet after > the initial efforts though. > Typo here. That should be http://fedoraproject.org/wiki/BugZappers. Sorry. -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From jspaleta at gmail.com Fri Dec 23 14:12:31 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 23 Dec 2005 09:12:31 -0500 Subject: KDE 3.5 In-Reply-To: References: <1135287812.3576.0.camel@bureau.maison> Message-ID: <604aa7910512230612r46395a63qc19bd25b63d1a33e@mail.gmail.com> On 12/23/05, Thomas M Steenholdt wrote: > I believe it's been mentioned on this list somewhere before, that > updates-testing is probably not getting the attention (it should?) from > a wide variety of testers. My feeling is that updates-testing is > *mostly* being used by people who have a bugzilla for productX and needs > to test if their bug has gone away and stuff like this. > This may or may not be intentional (or even true), but that's what I > seem to recall from previous discussions. I think you are wrong. The yum 2.4.1 to updates-testing definitely got noticed by several testers, and the bugs in the new caching feature were caught and fixed before it got pushed to updates-released. People are using updates-testing and it would have been perfectly suitable to spin up kde packages in updates-testing. And i think its absolutely absurb to make any claim about how the repo is being used. We have no stats on the usage pattern of updates-testing.. nor do we have ANY policy with regard to having testers register that they have tested a certain package. We have an unknown number of people testing an unknown percentage of the packages. We can't draw any conclusions from that. The fact that we don't have metrics on the testing pattern, is not an excuse to avoid providing the testing packages. Suck it up and provide the test packages. If people are really concerned about the amount of testing being done, then make it a policy that every testing update annoucement has a bug report referenced in the annoucement and have every tester provided a "i tested it" comment. Where updates-testing falls down is when hardware specific functionality needs testing. Coverage over a full spectrum of hardware isn't going to happen. Kernels in updates-testing are never going to get enough hardware coverage to catch every problem before the kernel moves to updates-released. I have run every single updates-testing kernel that has come over the wire.. and for my hardware and my configuration i've seldom noticed a problem. You can not expect updates-testing to get full hardware coverage, and you certaintly can't expect people to screw around as much trying different hardware configurations as compared to someone running rawhide. But for application layer software and most libraries beneath them... updates-testing packages can be useful and will get tested. You don't need comprehensive hardware coverage to catch problems with kde. You just need users who do everyday user things, in kde. > If it had been in updates-testing, would you have taken the time to > seriously and thoroughly testing it? If the existence of the kde 3.5 testing packages were made known in the forums and in fedora-list, then I'm pretty sure rabid kde users would show up and chew on the packages. -jef From thomas at apestaart.org Fri Dec 23 14:27:40 2005 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Fri, 23 Dec 2005 15:27:40 +0100 Subject: Royalty free gstreamer plug-in In-Reply-To: <43ABF07B.6060101@redhat.com> References: <43ABF07B.6060101@redhat.com> Message-ID: <1135348060.15650.31.camel@thomas.amantes> On Fri, 2005-12-23 at 18:11 +0530, Rahul Sundaram wrote: > Gianluca Sforna wrote: > > >Hi all, > >is this announce from Fluendo referenced here: > >http://www.osnews.com/story.php?news_id=13078 > >already being discussed at Fedora Legal? > > > >It would be really nice to finally have mp3 support OUTB in Fedora. > > > > > Thats what I thought too initially but unfortunately it doesnt change > the Free software situation even a tiny bit Could you expand a bit on what you mean by "the Free software situation" ? > If you want mp3 support in a region where software patents are enforced > you could use any recent version of RealPlayer or you can buy a > proprietary plugin from Fluendo Fluendo does not sell a proprietary plugin for mp3 playback. Fluendo gives away both MIT-licensed source code, as well as binaries that come with a patent license, built from this source code. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> My baby she knows the weight that I'm under <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From thomas at apestaart.org Fri Dec 23 14:29:03 2005 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Fri, 23 Dec 2005 15:29:03 +0100 Subject: Royalty free gstreamer plug-in In-Reply-To: <43ABF78F.7000506@redhat.com> References: <43ABF07B.6060101@redhat.com> <43ABF704.4070109@nicubunu.ro> <43ABF78F.7000506@redhat.com> Message-ID: <1135348143.15650.34.camel@thomas.amantes> On Fri, 2005-12-23 at 18:41 +0530, Rahul Sundaram wrote: > Hi > > > > > On the positive side, I think Fedora is allowed now to write in FAQ or > > release notes: "to play mp3 files, go to this specific Fluendo page, > > click and install the rpm" > > > We could have done that with RealPlayer long before. We dont do that > since we dont support proprietary formats. If you want a Free software > platform be prepared to support and use a Free and superior format like > Ogg. Thats my take on it. I think that's a great and courageous statement to make. The reason we're giving away this plug-in, legally, is because we feel users and distributions should be given the choice to allow their users to migrate from closed to open formats. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> If only you'd come back to me If you laid at my side wouldn't need no mojo pin to keep me satisfied <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From thomas at apestaart.org Fri Dec 23 14:35:48 2005 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Fri, 23 Dec 2005 15:35:48 +0100 Subject: Royalty free gstreamer plug-in In-Reply-To: <43ABEF65.30707@nicubunu.ro> References: <43ABEF65.30707@nicubunu.ro> Message-ID: <1135348548.15650.41.camel@thomas.amantes> Hi, > It appears Fluendo got redistribution rights for binaries, not for > source code - the relevant passage is "If you are living in a country > where the mp3 patents don't apply you can of course use the source code". Anyone is free to distribute this source code. There is nothing illegal about offering source code available for download, even if it implements concepts covered by patents. In fact, you can easily download official reference code for a wide range of codecs from the respective group's sites. Red Hat can sign a redistribution contract with Fluendo that allows them to also rebuild this source code into binaries to which Fluendo's patent license applies. So Fedora can include the .src.rpm for this plug-in (it's MIT, just like any other piece of MIT code), and they can include the binary .rpm built from it (if they sign this contract). The only question that matters, if I understand correctly, from Red Hat's point of view is: does it matter that if one of our users rebuilds this .src.rpm, he ends up with a binary .rpm that, while exactly the same as the one built by Red Hat, does not automatically come with a patent license - because it is not transferable from Red Hat to said user ? This is a fairly unique situation, and I'm sure it will need to be examined in more detail by lawyers and others. But I wouldn't be so quick to dismiss it as impossible to ship :) Also keep the following in mind; the MIT license was specifically chosen because it contains no specific language about patents, like the GPL does. You will find that all other mp3 decoding projects have chosen the GPL. Some of them did so because they know the GPL presents problems when it comes to patents, thus providing incentive to people who want to use their software to pay for an alternate license. This is one of the ways one can make money off of writing GPL software :) Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> nobody's interested in something you didn't do <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From sundaram at redhat.com Fri Dec 23 14:38:00 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 23 Dec 2005 20:08:00 +0530 Subject: Royalty free gstreamer plug-in In-Reply-To: <1135348060.15650.31.camel@thomas.amantes> References: <43ABF07B.6060101@redhat.com> <1135348060.15650.31.camel@thomas.amantes> Message-ID: <43AC0BC8.7080701@redhat.com> Hi >Could you expand a bit on what you mean by "the Free software >situation" ? > > The inability of distributions who want to support only open source software to distribute mp3 codecs >Fluendo does not sell a proprietary plugin for mp3 playback. Fluendo >gives away both MIT-licensed source code, as well as binaries that come >with a patent license, built from this source code. > > > Yes, you get a gratis codec but its still patent encumbered in many regions. People who are willing to accept and use a binary codec an use it. I am not belittling your work. Having a codec that works across the entire set of applications that use gstreamer is fabulous but it doesnt mean that Fedora can ship it unless they accept to ship a binary codec which is not what Fedora is all about. Real Player was available previously if the project wanted to do that. -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From sundaram at redhat.com Fri Dec 23 14:43:07 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 23 Dec 2005 20:13:07 +0530 Subject: Royalty free gstreamer plug-in In-Reply-To: <1135348548.15650.41.camel@thomas.amantes> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> Message-ID: <43AC0CFB.1060302@redhat.com> Hi > >Red Hat can sign a redistribution contract with Fluendo that allows them >to also rebuild this source code into binaries to which Fluendo's patent >license applies. > > > Yes. The requirement to sign up agreements with Fluendo is important here. We can choose to do that for RHEL but its a believe its a compromise to make one of the primary design principles of Fedora. >Also keep the following in mind; the MIT license was specifically chosen >because it contains no specific language about patents, like the GPL >does. You will find that all other mp3 decoding projects have chosen >the GPL. Some of them did so because they know the GPL presents >problems when it comes to patents, thus providing incentive to people >who want to use their software to pay for an alternate license. This is >one of the ways one can make money off of writing GPL software :) > > Yes. it is. Congrats on figuring out a Free software business model. The situation seems to be a bit more trickier than my understanding of it. I guess we need to call up the lawyers again to understand this more clearly. -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From sundaram at redhat.com Fri Dec 23 14:49:19 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 23 Dec 2005 20:19:19 +0530 Subject: Royalty free gstreamer plug-in In-Reply-To: <1135348143.15650.34.camel@thomas.amantes> References: <43ABF07B.6060101@redhat.com> <43ABF704.4070109@nicubunu.ro> <43ABF78F.7000506@redhat.com> <1135348143.15650.34.camel@thomas.amantes> Message-ID: <43AC0E6F.8070408@redhat.com> Hi >>We could have done that with RealPlayer long before. We dont do that >>since we dont support proprietary formats. If you want a Free software >>platform be prepared to support and use a Free and superior format like >>Ogg. Thats my take on it. >> >> > >I think that's a great and courageous statement to make. > Yes it is. > The reason >we're giving away this plug-in, legally, is because we feel users and >distributions should be given the choice to allow their users to migrate >from closed to open formats. > >Thomas > > Red Hat happens to be doing similar things all the time. Evince or GCJ for recent examples. Again I do believe your solution makes sense for a whole lot of people regardless of my stand on it. -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From sundaram at redhat.com Fri Dec 23 14:59:51 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 23 Dec 2005 20:29:51 +0530 Subject: Royalty free gstreamer plug-in In-Reply-To: <1135348060.15650.31.camel@thomas.amantes> References: <43ABF07B.6060101@redhat.com> <1135348060.15650.31.camel@thomas.amantes> Message-ID: <43AC10E7.7050003@redhat.com> Hi > Fluendo >gives away both MIT-licensed source code, as well as binaries that come >with a patent license, built from this source code. > > Right. So my reference to the Free software situation was that the plugin that has a patent license is a binary one. -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From jspaleta at gmail.com Fri Dec 23 15:05:03 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 23 Dec 2005 10:05:03 -0500 Subject: Royalty free gstreamer plug-in In-Reply-To: <1135348548.15650.41.camel@thomas.amantes> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> Message-ID: <604aa7910512230705u4e30ff03q6bc32d38800ff180@mail.gmail.com> On 12/23/05, Thomas Vander Stichele wrote: > So Fedora can include the .src.rpm for this plug-in (it's MIT, just like > any other piece of MIT code), and they can include the binary .rpm built > from it (if they sign this contract). > > The only question that matters, if I understand correctly, from Red > Hat's point of view is: does it matter that if one of our users rebuilds > this .src.rpm, he ends up with a binary .rpm that, while exactly the > same as the one built by Red Hat, does not automatically come with a > patent license - because it is not transferable from Red Hat to said > user ? > > This is a fairly unique situation, and I'm sure it will need to be > examined in more detail by lawyers and others. But I wouldn't be so > quick to dismiss it as impossible to ship :) > > Also keep the following in mind; the MIT license was specifically chosen > because it contains no specific language about patents, like the GPL > does. You will find that all other mp3 decoding projects have chosen > the GPL. Some of them did so because they know the GPL presents > problems when it comes to patents, thus providing incentive to people > who want to use their software to pay for an alternate license. This is > one of the ways one can make money off of writing GPL software :) The use of the MIT license is definitely a new and interesting twist in the debate. Sadly its going to have to be vetted by legal and we know what that means.... we'll know in 6 to 8 months if its legally okay to put this code into the fedora tree. I think the MIT license for this codebase definitely impacts the legal issues. But beyond legality and into policy...I'm not sure the issue of transferability of the patent license is a policy blocker. Doesn't fedora already ship items with trademark constraints that hamper verbatim rebuilds by downstream users? Mozilla's trademark policy specifically comes to mind. Yes.. trademarks is not the same as patents. And yes software patents are inherently evil and trademarks are inherently good. I'm just saying that we already have software in the tree that rebuilding and redistribution of is somewhat constrained beyond copyright allowances. We aren't adding additional headache for rebuilders that they don't already have to be aware of by including this MIT licensed source under signed contract. I think the policy question is bound up into the politics of how strongly fedora wants to draw a line in the sand about the licensing terms for software patents. Users who need and desire mp3 support are going to find a way to get mp3 support, there is no question about that. If Fedora tows a very strict policy of "hear no evil, see no evil" its not going to stop a single person from getting the software they need from a 3rd party source. What's the better way to serve and educate users? Drawing a very strict line and forcing people to google and find solutions on their own? Pointing out a specific 3rd party vendor to legally obtain the software while still holding a strict policy about excluding non-transferable patent licenses? Or providing as much technology that is legally allowed in the tree and letting downstream rebuilders deal with the additional patent license issues. -jef From nman64 at n-man.com Fri Dec 23 15:31:53 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Fri, 23 Dec 2005 09:31:53 -0600 Subject: Royalty free gstreamer plug-in In-Reply-To: <1135348548.15650.41.camel@thomas.amantes> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> Message-ID: <43AC1869.1000803@n-man.com> Thomas Vander Stichele wrote: > > Anyone is free to distribute this source code. There is nothing illegal > about offering source code available for download, even if it implements > concepts covered by patents. In fact, you can easily download official > reference code for a wide range of codecs from the respective group's > sites. > That is not accurate. Use of the MIT license doesn't change the patent situation. If patents were so easily defeated, it would have happened long ago. None of the licenses that Fluendo has will cover redistribution by others. It still remains problematic in the United States for us to redistribute this package. > Red Hat can sign a redistribution contract with Fluendo that allows them > to also rebuild this source code into binaries to which Fluendo's patent > license applies. > That might work for RHEL, but it is meaningless for Fedora, and basically a non-starter for any non-commercial redistribution who's looking for the legal way out. Even if it were included in RHEL, it would be much like the Java components that cannot be redistributed with the rest of the open source components. > So Fedora can include the .src.rpm for this plug-in (it's MIT, just like > any other piece of MIT code), and they can include the binary .rpm built > from it (if they sign this contract). > One of Fedora's policies is to enable downstream rebuilds and redistribution. Contracts are a no-go, and it is still no more legal for us to redistribute the source code. If the patent holders decide to go after people, they'd still be able to get us for that. > > This is a fairly unique situation, and I'm sure it will need to be > examined in more detail by lawyers and others. But I wouldn't be so > quick to dismiss it as impossible to ship :) > It does need to be examined by lawyers to establish its exact legal position, but it cannot be included in Fedora either way. > Also keep the following in mind; the MIT license was specifically chosen > because it contains no specific language about patents, like the GPL > does. > Lacking language about patents doesn't take away the liability. Quite the opposite, in fact. Using the MIT license is telling everyone else "Hey, if you get sued for using this, remember - our license didn't say anything about patents, and it didn't offer you any protections." -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ -- Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jspaleta at gmail.com Fri Dec 23 15:43:55 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 23 Dec 2005 10:43:55 -0500 Subject: Royalty free gstreamer plug-in In-Reply-To: <43AC0BC8.7080701@redhat.com> References: <43ABF07B.6060101@redhat.com> <1135348060.15650.31.camel@thomas.amantes> <43AC0BC8.7080701@redhat.com> Message-ID: <604aa7910512230743m1052c0c1g3eca07f059cb99@mail.gmail.com> On 12/23/05, Rahul Sundaram wrote: > Real Player was available > previously if the project wanted to do that. RealPlayer was a bit different... there was no source code available for real's codecs. and on top of that realplayer didnt really work inside the framework of other applications. It wasn't so much a "codec" as a seperate highly redudant and poorly integrated application. Who needs that crap. The gst plugin on the other hand has appropriately licensed source code, source code that Fedora can distribute and source code that can be redistributed by downstream users of Fedora. That's a huge difference from realplayer. The MIT copyright license has very different implications concerned re-distribution than the GPL licensed codebases we have seen before. The MIT license doesn't self-terminate re-distribution of the sourcecode when patent restrictions on binaries become invovled. The situation is definitely worth taking a closer look at. -jef From thomas at apestaart.org Fri Dec 23 15:45:41 2005 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Fri, 23 Dec 2005 16:45:41 +0100 Subject: Royalty free gstreamer plug-in In-Reply-To: <43AC1869.1000803@n-man.com> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> Message-ID: <1135352741.15650.54.camel@thomas.amantes> > That is not accurate. Use of the MIT license doesn't change the patent > situation. Could you expand on that point a bit ? Calling something "the patent situation" doesn't tell me exactly what you mean. FWIW, for most distributions the problem with mp3 code is precisely that all these decoders were GPL-licensed, and the GPL has a clause that terminates your right to distribute if you cannot distribute freely to all (remember, IANAL). So the problem was in the GPL, not in the code or in the fact that patents apply. Feel free to correct me if I'm missing something. > If patents were so easily defeated, it would have happened > long ago. This does not defeat patents. This only aims at achieving a very specific thing: allowing distros to ship both source code for a decoder, without violating the source code license, and binaries built from it, with the necessary patent license attached. One of the reasons this never happened before is because nobody wanted to invest in creating a MIT codebase to do so (remember - this means any other company can "rip Fluendo off" and repackage their code) - all free software decoders that I know of are under the GPL. > None of the licenses that Fluendo has will cover > redistribution by others. Are you sure ? Fluendo offers any distributor the possibility of signing a contract that allows distributors to rebuild binaries for which the patent license Fluendo negotiated is transferable. > That might work for RHEL, but it is meaningless for Fedora, and > basically a non-starter for any non-commercial redistribution who's > looking for the legal way out. Even if it were included in RHEL, it > would be much like the Java components that cannot be redistributed with > the rest of the open source components. > Lacking language about patents doesn't take away the liability. Quite > the opposite, in fact. Using the MIT license is telling everyone else > "Hey, if you get sued for using this, remember - our license didn't say > anything about patents, and it didn't offer you any protections." The point is that "use" of a piece of software applies to the binary, not the source code. You cannot get sued for having a piece of software code. You can get sued for distributing a working (in this case, binary) version of the code without the permission to do so, or for using a binary version for which you do not have a permission. Of course, IANAL, but if I'm wrong about this, please argue the specific points I'm wrong about. In this respect, any piece of code currently shipped by Fedora could be the subject of a lawsuit for any of the customers. Fedora is not guaranteeing their users they won't get sued for anything in the distro, so I don't see why it would be different for this particular package. Thanks for your insightful comments, I hope to form a clearer picture for myself on the situation. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> Is there a voice unkind in the back of your mind saying "maybe you didn't know him at all" <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From jspaleta at gmail.com Fri Dec 23 15:52:13 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 23 Dec 2005 10:52:13 -0500 Subject: Royalty free gstreamer plug-in In-Reply-To: <43AC1869.1000803@n-man.com> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> Message-ID: <604aa7910512230752p5f506333se69a4171abf6c811@mail.gmail.com> On 12/23/05, Patrick Barnes wrote: > One of Fedora's policies is to enable downstream rebuilds and > redistribution. 1) Fedora already has software where rebuilds are constrained by trademark law. I can not modify mozilla however i want and rebuild it and re-distribute it as "mozilla" because of mozilla's trademark policy. I have to get mozilla's permission to reuse the trademark and the branding. Fedora is already rebuilding 'impure' in the trademark sense. >Contracts are a no-go, and it is still no more legal > for us to redistribute the source code. Are you absolutely sure its not legal to redistribute MIT licensed source code without a contract for the patents? That's not my nonlawyer understanding. My understanding is, for GPL codebases, the GPL itself self-terminates your ability to redistribute the sourcecode when the patent constraints your ability to use the binary. This is the first opensource, non-GPL codebase for mp3 that I am aware of, so whatever understanding we have for how to GPL interacts with patents might not completely apply. -jef From nman64 at n-man.com Fri Dec 23 16:17:58 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Fri, 23 Dec 2005 10:17:58 -0600 Subject: Royalty free gstreamer plug-in In-Reply-To: <1135352741.15650.54.camel@thomas.amantes> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <1135352741.15650.54.camel@thomas.amantes> Message-ID: <43AC2336.3030909@n-man.com> Thomas Vander Stichele wrote: > > That is not accurate. Use of the MIT license doesn't change the patent > > situation. > > Could you expand on that point a bit ? Calling something "the patent > situation" doesn't tell me exactly what you mean. > > By "the patent situation", I mean that MP3 is covered by patents, and that to use or redistribute any technology that takes advantage of a patented technique, you must obtain a license from the patent holder. > FWIW, for most distributions the problem with mp3 code is precisely that > all these decoders were GPL-licensed, and the GPL has a clause that > terminates your right to distribute if you cannot distribute freely to > all (remember, IANAL). So the problem was in the GPL, not in the code > or in the fact that patents apply. > > Feel free to correct me if I'm missing something. > That is only part of it. The other part is that we are in the United States, where use of patented techniques without a license is illegal. Your licensing means we can redistribute from a copyright perspective, but we are still constrained by the patent. Under the GPL, we lose the copyright if the codebase is impacted by a patent. With the MIT license, we still have a copyright license even though the technology is covered by a patent, but it is still illegal for us to use and redistribute the technology without a patent license. > > If patents were so easily defeated, it would have happened > > long ago. > > This does not defeat patents. This only aims at achieving a very > specific thing: allowing distros to ship both source code for a decoder, > without violating the source code license, and binaries built from it, > with the necessary patent license attached. > The point is that a contract is still needed for the binaries. We could have gotten a patent license before, but we will not be given a patent license that automatically covers us and all downstream users and distributors. Thanks to you, we have something we can distribute from a copyright perspective, but not a patent perspective. > One of the reasons this never happened before is because nobody wanted > to invest in creating a MIT codebase to do so (remember - this means any > other company can "rip Fluendo off" and repackage their code) - all free > software decoders that I know of are under the GPL. > This is something unique, and parts of the community can thank you for it. Unfortunately, it doesn't help Fedora or others who still have to worry about the patent constraints. > > None of the licenses that Fluendo has will cover > > redistribution by others. > > Are you sure ? Fluendo offers any distributor the possibility of signing > a contract that allows distributors to rebuild binaries for which the > patent license Fluendo negotiated is transferable. > That contract is a killer. Also, it wouldn't make much sense for us to include a plugin that can only be used with other non-GPL software. Most of the software in Fedora that uses the gstreamer backend is GPL software. This solution is GPL-incompatible, and that causes a lot of problems that are hard to overlook. > > That might work for RHEL, but it is meaningless for Fedora, and > > basically a non-starter for any non-commercial redistribution who's > > looking for the legal way out. Even if it were included in RHEL, it > > would be much like the Java components that cannot be redistributed with > > the rest of the open source components. > > > Lacking language about patents doesn't take away the liability. Quite > > the opposite, in fact. Using the MIT license is telling everyone else > > "Hey, if you get sued for using this, remember - our license didn't say > > anything about patents, and it didn't offer you any protections." > > The point is that "use" of a piece of software applies to the binary, > not the source code. You cannot get sued for having a piece of software > code. You can get sued for distributing a working (in this case, > binary) version of the code without the permission to do so, or for > using a binary version for which you do not have a permission. Of > course, IANAL, but if I'm wrong about this, please argue the specific > points I'm wrong about. > > In this respect, any piece of code currently shipped by Fedora could be > the subject of a lawsuit for any of the customers. Fedora is not > guaranteeing their users they won't get sued for anything in the distro, > so I don't see why it would be different for this particular package. > Fedora isn't making any guarantees, but we are trying hard to protect our users and downstream distributors. NTFS is a similar situation. http://fedoraproject.org/wiki/ForbiddenItems isn't just for us, it is for us, our users, and downstream distributors and builders. > Thanks for your insightful comments, I hope to form a clearer picture > for myself on the situation. > > Thomas > > > Dave/Dina : future TV today ! - http://www.davedina.org/ > <-*- thomas (dot) apestaart (dot) org -*-> > Is there a voice unkind > in the back of your mind > saying "maybe you didn't know him at all" > <-*- thomas (at) apestaart (dot) org -*-> > URGent, best radio on the net - 24/7 ! - http://urgent.fm/ > > > > What you're doing and what you're trying to do is great, but there is a distinct reason that MP3 has been such a problem in the past. You've made some progress, but we are still a long way away from being where we need to be in order to have free MP3. The patent holder doesn't want their technology in the wild, and until they are ready to release their hold, that situation won't change. Many thanks, congratulations, and good work, but there's still a lot that has to happen before Fedora can have MP3 support. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ -- Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jspaleta at gmail.com Fri Dec 23 16:26:21 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 23 Dec 2005 11:26:21 -0500 Subject: Royalty free gstreamer plug-in In-Reply-To: <43AC2336.3030909@n-man.com> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <1135352741.15650.54.camel@thomas.amantes> <43AC2336.3030909@n-man.com> Message-ID: <604aa7910512230826u4c22d27ftdfb051dd1605da18@mail.gmail.com> On 12/23/05, Patrick Barnes wrote: > By "the patent situation", I mean that MP3 is covered by patents, and > that to use or redistribute any technology that takes advantage of a > patented technique, you must obtain a license from the patent holder. Assuming this statement about requiring generally requiring a contract for patent encombered sourcecode is true and the statement that Fedora doesn't contract for patents is also true.. can you explain why the freetype package that ships in Core includes the source code for the patented byte interpreter? You know the bytecode intepreter that can be re-enabled with a simple rebuild of freetype src.rpm by switching a predefined specfile macro %define without_bytecode_interpreter from 0 to 1? I honestly can't reconcile either claim you make about the general situation in a way the explains why freetype is shipped in fedora the way that it is. -jef From nman64 at n-man.com Fri Dec 23 16:26:28 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Fri, 23 Dec 2005 10:26:28 -0600 Subject: Royalty free gstreamer plug-in In-Reply-To: <604aa7910512230752p5f506333se69a4171abf6c811@mail.gmail.com> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <604aa7910512230752p5f506333se69a4171abf6c811@mail.gmail.com> Message-ID: <43AC2534.2090903@n-man.com> Jeff Spaleta wrote: > On 12/23/05, Patrick Barnes wrote: > > One of Fedora's policies is to enable downstream rebuilds and > > redistribution. > > 1) Fedora already has software where rebuilds are constrained by trademark law. > I can not modify mozilla however i want and rebuild it and > re-distribute it as "mozilla" because of mozilla's trademark policy. I > have to get mozilla's permission to reuse the trademark and the > branding. Fedora is already rebuilding 'impure' in the trademark > sense. > Fedora is the same way. You can't modify it and continue to call it Fedora. However, you can redistribute it and rebuild it in pristine form and continue to call it Fedora. The same is true of Mozilla. The free software licenses we support aren't meant to work around trademarks. Trademarks are very important, and very different from patents. You are not free to build, use, and redistribute technologies that use patented techniques, even in pristine form. > >Contracts are a no-go, and it is still no more legal > > for us to redistribute the source code. > > Are you absolutely sure its not legal to redistribute MIT licensed > source code without a contract for the patents? That's not my > nonlawyer understanding. My understanding is, for GPL codebases, the > GPL itself self-terminates your ability to redistribute the sourcecode > when the patent constraints your ability to use the binary. This is > the first opensource, non-GPL codebase for mp3 that I am aware of, so > whatever understanding we have for how to GPL interacts with patents > might not completely apply. > > > -jef > > You've almost got it right. The GPL self-terminates without patent freedom. This means that if you don't have patent rights, you don't have copyrights either. With the MIT license, you still have copyrights even if you don't have patent rights. The problem is that we would still need patent rights for MP3 technology to build, use and distribute this MP3 plugin. Also, this solution is GPL-incompatible, meaning we can't integrate this plugin with GPL software. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ -- Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From nman64 at n-man.com Fri Dec 23 16:31:48 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Fri, 23 Dec 2005 10:31:48 -0600 Subject: Royalty free gstreamer plug-in In-Reply-To: <604aa7910512230826u4c22d27ftdfb051dd1605da18@mail.gmail.com> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <1135352741.15650.54.camel@thomas.amantes> <43AC2336.3030909@n-man.com> <604aa7910512230826u4c22d27ftdfb051dd1605da18@mail.gmail.com> Message-ID: <43AC2674.6060601@n-man.com> Jeff Spaleta wrote: > On 12/23/05, Patrick Barnes wrote: > > By "the patent situation", I mean that MP3 is covered by patents, and > > that to use or redistribute any technology that takes advantage of a > > patented technique, you must obtain a license from the patent holder. > > Assuming this statement about requiring generally requiring a contract > for patent encombered sourcecode is true and the statement that Fedora > doesn't contract for patents is also true.. can you explain why the > freetype package that ships in Core includes the source code for the > patented byte interpreter? You know the bytecode intepreter that can > be re-enabled with a simple rebuild of freetype src.rpm by switching a > predefined specfile macro %define without_bytecode_interpreter from 0 > to 1? > > I honestly can't reconcile either claim you make about the general > situation in a way the explains why freetype is shipped in fedora the > way that it is. > > -jef > > The issue is that we don't just distribute the software in source form, and we want users and downstream to be able to build and use the software, too. We would also need a patent license that covers all users and downstream before we could include this in the distribution. We can't get a contract that does that for us. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ -- Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jspaleta at gmail.com Fri Dec 23 16:30:55 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 23 Dec 2005 11:30:55 -0500 Subject: Royalty free gstreamer plug-in In-Reply-To: <43AC2534.2090903@n-man.com> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <604aa7910512230752p5f506333se69a4171abf6c811@mail.gmail.com> <43AC2534.2090903@n-man.com> Message-ID: <604aa7910512230830q22353473xa38f3e682dc01bfc@mail.gmail.com> On 12/23/05, Patrick Barnes wrote: > Also, this solution is GPL-incompatible, meaning we > can't integrate this plugin with GPL software. who cares.... we have lots of GPL incompatible code in Fedora. I don't even know why you bring this up. gst is LGPL and we are talking about a runtime detected plugin to gst. -jef From thomas at apestaart.org Fri Dec 23 16:38:06 2005 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Fri, 23 Dec 2005 17:38:06 +0100 Subject: Royalty free gstreamer plug-in In-Reply-To: <43AC2336.3030909@n-man.com> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <1135352741.15650.54.camel@thomas.amantes> <43AC2336.3030909@n-man.com> Message-ID: <1135355886.15650.68.camel@thomas.amantes> On Fri, 2005-12-23 at 10:17 -0600, Patrick Barnes wrote: > Thomas Vander Stichele wrote: > > > That is not accurate. Use of the MIT license doesn't change the patent > > > situation. > > > > Could you expand on that point a bit ? Calling something "the patent > > situation" doesn't tell me exactly what you mean. > > > > > By "the patent situation", I mean that MP3 is covered by patents, and > that to use or redistribute any technology that takes advantage of a > patented technique, you must obtain a license from the patent holder. Just to make sure I follow you - this only applies to the binaries, correct ? We both agree that patent law does not stop you from shipping source code that implements patented techniques ? As an example - I can take the freetype2 .src.rpm in Fedora and rebuild it with a switch to turn on the patented hinting techniques. Fedora is shipping a piece of source code that implements patented techniques. I just want to make sure we are only talking about the "patent situation" when it comes to the binaries. > That is only part of it. The other part is that we are in the United > States, where use of patented techniques without a license is illegal. > Your licensing means we can redistribute from a copyright perspective, > but we are still constrained by the patent. Under the GPL, we lose the > copyright if the codebase is impacted by a patent. No - you lose the ability to distribute the software under the GPL because the GPL itself terminates itself. AFAIK this is unrelated to copyright. > The point is that a contract is still needed for the binaries. Yes, exactly. There's no other way to satisfy the upstream patent license requirements. > > Are you sure ? Fluendo offers any distributor the possibility of signing > > a contract that allows distributors to rebuild binaries for which the > > patent license Fluendo negotiated is transferable. > > > That contract is a killer. Can you expand on that ? What makes it a killer ? > Also, it wouldn't make much sense for us to > include a plugin that can only be used with other non-GPL software. > Most of the software in Fedora that uses the gstreamer backend is GPL > software. Totem is licensed under the GPL with the added exception/clarification to allow for binary plugins to be used with it through GStreamer. A lawyer needs to decide if this is an interpretation of the GPL as intended by the author (much like the situation for kernel modules) or if it is an explicit exception. It was also discussed with Rhythmbox developers - I don't know if that got decided upon. The author of sound-juicer is going to add this exception as well. > What you're doing and what you're trying to do is great, but there is a > distinct reason that MP3 has been such a problem in the past. You've > made some progress, but we are still a long way away from being where we > need to be in order to have free MP3. I don't think there will be free mp3 the way there is free Vorbis until the patents expire. FWIW, I'm not necessarily arguing Fedora should ship it. I think it would be great if Fedora would make a statement by saying "we don't want to put this in the distribution because it is not a free format". I would be happy if Fedora would be sending users that message. All of my 100+GB of music at home is in Ogg/Vorbis :) Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> Bye bye long day need to sleep so much ninety hours straight <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From seanlkml at sympatico.ca Fri Dec 23 16:41:46 2005 From: seanlkml at sympatico.ca (Sean) Date: Fri, 23 Dec 2005 11:41:46 -0500 (EST) Subject: Royalty free gstreamer plug-in In-Reply-To: <43AC2534.2090903@n-man.com> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <604aa7910512230752p5f506333se69a4171abf6c811@mail.gmail.com> <43AC2534.2090903@n-man.com> Message-ID: On Fri, December 23, 2005 11:26 am, Patrick Barnes said: > You've almost got it right. The GPL self-terminates without patent > freedom. This means that if you don't have patent rights, you don't have > copyrights either. With the MIT license, you still have copyrights even > if you don't have patent rights. The problem is that we would still need > patent rights for MP3 technology to build, use and distribute this MP3 > plugin. Also, this solution is GPL-incompatible, meaning we can't > integrate this plugin with GPL software. > Hmmm I don't pretend to understand this stuff, but the GPL text seems pretty clear on this matter: "For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program." So the only question is, is the gstreamer mp3 plugin patent free or not? Sean From jspaleta at gmail.com Fri Dec 23 16:45:37 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 23 Dec 2005 11:45:37 -0500 Subject: Royalty free gstreamer plug-in In-Reply-To: <43AC2534.2090903@n-man.com> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <604aa7910512230752p5f506333se69a4171abf6c811@mail.gmail.com> <43AC2534.2090903@n-man.com> Message-ID: <604aa7910512230845u254404eap1d0ff9a58deba7ed@mail.gmail.com> On 12/23/05, Patrick Barnes wrote: > Fedora is the same way. You can't modify it and continue to call it > Fedora. However, you can redistribute it and rebuild it in pristine > form and continue to call it Fedora. The same is true of Mozilla. I do not think its true that a pristine build of the src.rpm as shipped for mozilla by fedora is allowed according to Mozilla's trademark policy. I have looked at this.. alot. The Mozilla trademark policy says that you can not use the trademarked mozilla icons in your rebuild of the mozilla sources unless you get permission to do so. Even if you think its a verbatim rebuild of a licensed binary. The upstream mozilla sources are constructed in a way that default rebuilds do not incorporate the mozilla trademarks. To get the mozilla trademark icons into the build process you need to use some optional arguments to the configure script to enabled them. This is done explicitly to avoid people accidently running afoul of the trademark policy. To use the mozilla trademarks in your downstream build you must get permission from Mozilla... no if ands or buts. This doesn't transfer to verbatim rebuilds. There is absolutely no languge in Mozilla's trademark policy that says trademark license to use the mozilla marks transfer to a 3rd vendor with verbatim rebuilds from an existing licensed binary from a 2nd vendor. Each new vendor who is rebuilding mozilla source must obtain a license to use the mozilla marks regardless of where they obtained the source they are rebuilding from. Fedora has permission to use the trademarks in its builds and the Fedora src.rpms enable the use of the trademark icons. I have seen absolutely no language anywhere that tranfers this permission to use the mozilla marks to anyone doing unmodified rebuilds of Fedora mozilla packages. Anyone rebuilding with src.rpms from Fedora and attempts to redistribute them also end up using the trademarked icons unless they delibrately turn them off... even though they do not have permission from mozilla to use those icons. This situation breaks the "pure rebuild" policy. Anyone rebuilding mozilla packages from fedora sources, even if unmodified.. must get permission from mozilla to use the trademarks. I'm more than welcome to be contradicted by the mozilla package maintainer or someone else on the release team who has looked over the mozilla trademark policy issues. -jef From seanlkml at sympatico.ca Fri Dec 23 16:45:41 2005 From: seanlkml at sympatico.ca (Sean) Date: Fri, 23 Dec 2005 11:45:41 -0500 (EST) Subject: Royalty free gstreamer plug-in In-Reply-To: <48155.10.10.10.28.1135356106.squirrel@linux1> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <604aa7910512230752p5f506333se69a4171abf6c811@mail.gmail.com> <43AC2534.2090903@n-man.com> <48155.10.10.10.28.1135356106.squirrel@linux1> Message-ID: On Fri, December 23, 2005 11:41 am, Sean said: > Hmmm I don't pretend to understand this stuff, but the GPL text seems > pretty clear on this matter: > > "For example, if a patent license would not permit royalty-free > redistribution of the Program by all those who receive copies directly or > indirectly through you, then the only way you could satisfy both it and > this License would be to refrain entirely from distribution of the > Program." > > So the only question is, is the gstreamer mp3 plugin patent free or not? > Doh, this doesn't really apply since nobody is trying to distribute this code under the GPL... nevermind.. i'll leave this debate to brighter legal minds than me.. Sean From nicolas.mailhot at laposte.net Fri Dec 23 16:51:34 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 23 Dec 2005 17:51:34 +0100 Subject: Royalty free gstreamer plug-in In-Reply-To: <1135352741.15650.54.camel@thomas.amantes> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <1135352741.15650.54.camel@thomas.amantes> Message-ID: <43AC2B16.6040208@laposte.net> Thomas Vander Stichele wrote: >> That is not accurate. Use of the MIT license doesn't change the patent >> situation. > > Could you expand on that point a bit ? Calling something "the patent > situation" doesn't tell me exactly what you mean. > > FWIW, for most distributions the problem with mp3 code is precisely that > all these decoders were GPL-licensed, and the GPL has a clause that > terminates your right to distribute if you cannot distribute freely to > all (remember, IANAL). So the problem was in the GPL, not in the code > or in the fact that patents apply. Red Hat in general and Fedora in particular are a tad different. So far Red Hat has not seen GPL and other FOSS licensing as constraints that need to be worked around to earn money, but was always very serious about promoting clean FOSS practices (as evidenced by the re-licensings of the assets they bought, early Gnome support, etc). Lots of distros have tried clever licensing schemes to get around FOSS IP "problems". Caldera was marketed as the distro for businesses (ie people who gave dang about FOSS ethics). Mandriva has often played this game too. For a very long time Suse didn't want to free yast. Need I write about ndsiwraper too ? Well the market chose. It seems people that matter (which influence purchases) care more about FOSS ethics than marketing people think. At this point squandering all the goodwill accrued by taking a firm FOSS stand would be something very stupid for Red Hat to do. Because your offer is very nice, and as a user I welcome it, but I would never make a long-term commitment to a distro that swallowed such a poison pill. I might as well start using Solaris. People write about Red Hat being the next Microsoft (or other such stupid things). The truth is the software Fedora delivers is as ethically pure as Debian's, and at least you don't have to wait years for it to get out of the release process. -- Nicolas Mailhot From jspaleta at gmail.com Fri Dec 23 16:57:44 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 23 Dec 2005 11:57:44 -0500 Subject: Royalty free gstreamer plug-in In-Reply-To: <43AC2674.6060601@n-man.com> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <1135352741.15650.54.camel@thomas.amantes> <43AC2336.3030909@n-man.com> <604aa7910512230826u4c22d27ftdfb051dd1605da18@mail.gmail.com> <43AC2674.6060601@n-man.com> Message-ID: <604aa7910512230857j12d52d0eo52e25a0877b4a4da@mail.gmail.com> On 12/23/05, Patrick Barnes wrote: > The issue is that we don't just distribute the software in source form, > and we want users and downstream to be able to build and use the > software, too. You ducked the question i asked about reconcilation of your statements nicely. Yes we would like very much if software patents disappeared off the face of the planet completely. Let's all hold our breath waiting for that to happen. >We would also need a patent license that covers all > users and downstream before we could include this in the distribution. > We can't get a contract that does that for us. Need and want... are two very different words. I really don't know how important it is that the full tree be rebuildable without additional constraint placed on the downstream rebuilder. I think trademark policy as it stands makes that a very poorly defined goal. So what if a rebuilder has to exclude this mp3 codec plugin when rebuilding. He has to to exclude the fedora-logos package as well. Excluding this one package as a rebuilder is nothing compared to the pain of replacing the trademarked logos inside packages. -jef From sundaram at redhat.com Fri Dec 23 16:59:13 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 23 Dec 2005 22:29:13 +0530 Subject: Royalty free gstreamer plug-in In-Reply-To: <1135355886.15650.68.camel@thomas.amantes> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <1135352741.15650.54.camel@thomas.amantes> <43AC2336.3030909@n-man.com> <1135355886.15650.68.camel@thomas.amantes> Message-ID: <43AC2CE1.5040400@redhat.com> Hi >Just to make sure I follow you - this only applies to the binaries, >correct ? We both agree that patent law does not stop you from shipping >source code that implements patented techniques ? > > I am not sure about that. Even if everyone agrees on that here we still might need to consult the legal team before proceeding with this. Everyone here might reach a position that makes the obvious sense but thats not necessary what the law says. So lets talk to the counsel and halt the discussion for now. -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From sopwith at redhat.com Fri Dec 23 16:59:24 2005 From: sopwith at redhat.com (Elliot Lee) Date: Fri, 23 Dec 2005 11:59:24 -0500 (EST) Subject: Royalty free gstreamer plug-in In-Reply-To: <1135355886.15650.68.camel@thomas.amantes> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <1135352741.15650.54.camel@thomas.amantes> <43AC2336.3030909@n-man.com> <1135355886.15650.68.camel@thomas.amantes> Message-ID: On Fri, 23 Dec 2005, Thomas Vander Stichele wrote: > Just to make sure I follow you - this only applies to the binaries, > correct ? We both agree that patent law does not stop you from shipping > source code that implements patented techniques ? Even this is questionable. It depends a lot on what constitutes patent infringement. Wikipedia sez "In U.S. law, an infringement may occur where the defendant has made, used, sold, offered to sell, or imported the infringing invention or its equivalent." Because software patents, such as the MP3 ones, typically claim a "method by which X happens", the source code could be argued to be the equivalent of the invention described in the MP3 patents' claims. Form doesn't seem to be important in patent law, only function - see http://en.wikipedia.org/wiki/Doctrine_of_equivalents I think a lot of this discussion here consists of us trying to be patent lawyers when we're not. While free software hackers are generally much more aware of IP law than your average Joe, we're just missing too much knowledge of patent case law and general "legal flavor" to have any idea which way this goes, legally speaking. I expect there will be future developments in the media formats area of Fedora, but for now it seems unlikely that we will do more than link to the packages you have kindly made available. Best, -- Elliot Red Hat Summit Nashville (May 30 - June 2, 2006) http://www.redhat.com/promo/summit/ From nicolas.mailhot at laposte.net Fri Dec 23 17:04:17 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 23 Dec 2005 18:04:17 +0100 Subject: Royalty free gstreamer plug-in In-Reply-To: <604aa7910512230752p5f506333se69a4171abf6c811@mail.gmail.com> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <604aa7910512230752p5f506333se69a4171abf6c811@mail.gmail.com> Message-ID: <43AC2E11.2070004@laposte.net> Jeff Spaleta wrote: > On 12/23/05, Patrick Barnes wrote: >> One of Fedora's policies is to enable downstream rebuilds and >> redistribution. > > 1) Fedora already has software where rebuilds are constrained by trademark law. > I can not modify mozilla however i want and rebuild it and > re-distribute it as "mozilla" because of mozilla's trademark policy. I > have to get mozilla's permission to reuse the trademark and the > branding. Fedora is already rebuilding 'impure' in the trademark > sense. And this does not matter at all because you still can produce a legit isofunctional package starting from Fedora sources (with a little work). This particular case is very different : the result of a rebuilt will *never* be legal, even with some code patching. So IMHO it's a big NO-GO. The essence of the FOSS movement is you can take up from where others left you, and this offer clearly forbids this Regards, -- Nicolas Mailhot From thomas at apestaart.org Fri Dec 23 17:02:48 2005 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Fri, 23 Dec 2005 18:02:48 +0100 Subject: Royalty free gstreamer plug-in In-Reply-To: <43AC2B16.6040208@laposte.net> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <1135352741.15650.54.camel@thomas.amantes> <43AC2B16.6040208@laposte.net> Message-ID: <1135357368.15650.71.camel@thomas.amantes> Hi, > Well the market chose. It seems people that matter (which influence > purchases) care more about FOSS ethics than marketing people think. At > this point squandering all the goodwill accrued by taking a firm FOSS > stand would be something very stupid for Red Hat to do. I think that is a good position to take. It's a different position to take than saying "we can't ship this for legal reasons". > People write about Red Hat being the next Microsoft (or other such > stupid things). The truth is the software Fedora delivers is as > ethically pure as Debian's, In some cases even more - Debian is still shipping GPL'd mp3 decoding code as part of the main distribution; see a recent discussion on debian-legal. Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> I got your phone number baby Call you sometime Think I might go out tonight Maybe give you a ride <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From thomas at apestaart.org Fri Dec 23 17:05:18 2005 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Fri, 23 Dec 2005 18:05:18 +0100 Subject: Royalty free gstreamer plug-in In-Reply-To: References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <1135352741.15650.54.camel@thomas.amantes> <43AC2336.3030909@n-man.com> <1135355886.15650.68.camel@thomas.amantes> Message-ID: <1135357518.15650.75.camel@thomas.amantes> On Fri, 2005-12-23 at 11:59 -0500, Elliot Lee wrote: > On Fri, 23 Dec 2005, Thomas Vander Stichele wrote: > > > Just to make sure I follow you - this only applies to the binaries, > > correct ? We both agree that patent law does not stop you from shipping > > source code that implements patented techniques ? > > Even this is questionable. I am not 100% sure of this either. But there are enough examples out there of companies doing this. Lots of sample code available from Intel's website for IPP can decode a whole range of patent-encumbered formats, to give but one example. Are they infringing by doing so ? > I think a lot of this discussion here consists of us trying to be patent > lawyers when we're not. Agreed :) It just seems like it should at least get some legal review from Red Hat lawyers instead of being dismissed out of hand. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> If I say goodbye to love will it go away ? <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From nicolas.mailhot at laposte.net Fri Dec 23 17:11:01 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 23 Dec 2005 18:11:01 +0100 Subject: Royalty free gstreamer plug-in In-Reply-To: <604aa7910512230857j12d52d0eo52e25a0877b4a4da@mail.gmail.com> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <1135352741.15650.54.camel@thomas.amantes> <43AC2336.3030909@n-man.com> <604aa7910512230826u4c22d27ftdfb051dd1605da18@mail.gmail.com> <43AC2674.6060601@n-man.com> <604aa7910512230857j12d52d0eo52e25a0877b4a4da@mail.gmail.com> Message-ID: <43AC2FA5.1030601@laposte.net> Jeff Spaleta wrote: > Need and want... are two very different words. I really don't know > how important it is that the full tree be rebuildable without > additional constraint placed on the downstream rebuilder. I think > trademark policy as it stands makes that a very poorly defined goal. > So what if a rebuilder has to exclude this mp3 codec plugin when > rebuilding. He has to to exclude the fedora-logos package as well. > Excluding this one package as a rebuilder is nothing compared to the > pain of replacing the trademarked logos inside packages. But you can do it (CentOS does) That's the whole point. To be allowed to take Fedora Core and do something else with it, if you disagree with Red Hat policies. This proposal OTOH is pretty much your take it or leave it traditional closed software offer. -- Nicolas Mailhot From sundaram at redhat.com Fri Dec 23 17:13:52 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 23 Dec 2005 22:43:52 +0530 Subject: Royalty free gstreamer plug-in In-Reply-To: <1135357368.15650.71.camel@thomas.amantes> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <1135352741.15650.54.camel@thomas.amantes> <43AC2B16.6040208@laposte.net> <1135357368.15650.71.camel@thomas.amantes> Message-ID: <43AC3050.6030106@redhat.com> Thomas Vander Stichele wrote: >Hi, > > > >>Well the market chose. It seems people that matter (which influence >>purchases) care more about FOSS ethics than marketing people think. At >>this point squandering all the goodwill accrued by taking a firm FOSS >>stand would be something very stupid for Red Hat to do. >> >> > >I think that is a good position to take. It's a different position to >take than saying "we can't ship this for legal reasons". > > The legal situation is unclear and we have to fallback on lawyers for that but the principles of Fedora clearly is or should be to everyone involved in the community. >In some cases even more - Debian is still shipping GPL'd mp3 decoding >code as part of the main distribution; see a recent discussion on >debian-legal. > > Debian is not a commercial organization in the US. IMO Debian is taking a legal risk by doing this but even if they get sued, then the court can just order them to stop. They dont have to worry about losing money. Red Hat can lose millions. For anyone wanting to sue Red Hat is a better target than Debian for the same reasons unfortunately and hence we have to be even more cautious about what we do compared to Debian et al. Fedora Foundation might change *some* aspects of this but the design principles dont go away. -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From dwmw2 at infradead.org Fri Dec 23 17:27:33 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Fri, 23 Dec 2005 17:27:33 +0000 Subject: Too much time wasted installing fedora on raid1 In-Reply-To: <20051222143334.GA27272@devserv.devel.redhat.com> References: <20051219201653.GU1556@stingr.net> <1135026753.2947.23.camel@laptopd505.fenrus.org> <20051220085657.GW1556@stingr.net> <1135071978.2952.8.camel@laptopd505.fenrus.org> <20051220101303.GB23000@ryoko.camperquake.de> <1135073956.2952.10.camel@laptopd505.fenrus.org> <1135082117.3154.5.camel@localhost.localdomain> <20051222112517.GA3648@devserv.devel.redhat.com> <1135252544.3557.19.camel@pmac.infradead.org> <20051222143334.GA27272@devserv.devel.redhat.com> Message-ID: <1135358853.6422.9.camel@pmac.infradead.org> On Thu, 2005-12-22 at 09:33 -0500, Alan Cox wrote: > Its a neccessary part of RAID because duplicating raid functionality in every > file system would be incredibly inefficient and lead to a lot of code > duplication and bug. Its also neccessary because the raid functionality may > not even be on the same host as the file system. A bit like the way that duplicating ATA functionality in every SATA host driver also leads to a lot of code duplication and bugs? Or the way that duplicating zlib in everything that needs compression leads to a lot of code duplication and bugs? The former doesn't happen; the latter was a bug which got fixed. -- dwmw2 From nman64 at n-man.com Fri Dec 23 17:32:46 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Fri, 23 Dec 2005 11:32:46 -0600 Subject: Royalty free gstreamer plug-in In-Reply-To: References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <1135352741.15650.54.camel@thomas.amantes> <43AC2336.3030909@n-man.com> <1135355886.15650.68.camel@thomas.amantes> Message-ID: <43AC34BE.6000304@n-man.com> Elliot Lee wrote: > On Fri, 23 Dec 2005, Thomas Vander Stichele wrote: > > > Just to make sure I follow you - this only applies to the binaries, > > correct ? We both agree that patent law does not stop you from shipping > > source code that implements patented techniques ? > > Even this is questionable. It depends a lot on what constitutes patent > infringement. Wikipedia sez "In U.S. law, an infringement may occur where > the defendant has made, used, sold, offered to sell, or imported the > infringing invention or its equivalent." Because software patents, such as > the MP3 ones, typically claim a "method by which X happens", the source > code could be argued to be the equivalent of the invention described in > the MP3 patents' claims. Form doesn't seem to be important in patent law, > only function - see http://en.wikipedia.org/wiki/Doctrine_of_equivalents > > I think a lot of this discussion here consists of us trying to be patent > lawyers when we're not. While free software hackers are generally much > more aware of IP law than your average Joe, we're just missing too much > knowledge of patent case law and general "legal flavor" to have any idea > which way this goes, legally speaking. > > I expect there will be future developments in the media formats area of > Fedora, but for now it seems unlikely that we will do more than link to > the packages you have kindly made available. > > Best, > -- Elliot > Red Hat Summit Nashville (May 30 - June 2, 2006) > http://www.redhat.com/promo/summit/ > > While my view is that the patent would cover only the binary form, legal precedent suggests that the patent also covers the source form. A fine example of this would be the DVD decryption code - which has been deemed illegal in U.S. courts. As far as Fedora is concerned, this is a moot point. I can't think of any examples of entire packages that we distribute only in source form. Packages that we cannot build and distribute in binary form and that downstream cannot build and distribute (without regard to contracts) have typically been excluded and left to projects like Livna. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ -- Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From nman64 at n-man.com Fri Dec 23 17:35:30 2005 From: nman64 at n-man.com (Patrick Barnes) Date: Fri, 23 Dec 2005 11:35:30 -0600 Subject: Royalty free gstreamer plug-in In-Reply-To: <604aa7910512230830q22353473xa38f3e682dc01bfc@mail.gmail.com> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <604aa7910512230752p5f506333se69a4171abf6c811@mail.gmail.com> <43AC2534.2090903@n-man.com> <604aa7910512230830q22353473xa38f3e682dc01bfc@mail.gmail.com> Message-ID: <43AC3562.5000103@n-man.com> Jeff Spaleta wrote: > On 12/23/05, Patrick Barnes wrote: > > Also, this solution is GPL-incompatible, meaning we > > can't integrate this plugin with GPL software. > > who cares.... we have lots of GPL incompatible code in Fedora. I don't > even know why you bring this up. gst is LGPL and we are talking about > a runtime detected plugin to gst. > > -jef > > This affects the players, too. Theoretically, by law, we could not use this plugin with Rhythmbox, but we could with Totem. Our use of GPL-incompatible code is really something we need to watch carefully, as there is also room for legal interpretation on this matter. I'll leave those determinations to RH legal, though. -- Patrick "The N-Man" Barnes nman64 at n-man.com http://www.n-man.com/ -- Have I been helpful? Rate my assistance! http://rate.affero.net/nman64/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: OpenPGP digital signature URL: From jspaleta at gmail.com Fri Dec 23 17:42:31 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 23 Dec 2005 12:42:31 -0500 Subject: Royalty free gstreamer plug-in In-Reply-To: References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <1135352741.15650.54.camel@thomas.amantes> <43AC2336.3030909@n-man.com> <1135355886.15650.68.camel@thomas.amantes> Message-ID: <604aa7910512230942q25651cbdqb121cf74d53537ab@mail.gmail.com> On 12/23/05, Elliot Lee wrote: > I expect there will be future developments in the media formats area of > Fedora, but for now it seems unlikely that we will do more than link to > the packages you have kindly made available. Even being able to link to this software as a prefered legal means to get mp3 support worth be a noteworthy change in the legal landscape. -jef From stickster at gmail.com Fri Dec 23 17:49:00 2005 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 23 Dec 2005 12:49:00 -0500 Subject: Royalty free gstreamer plug-in In-Reply-To: <43AC34BE.6000304@n-man.com> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <1135352741.15650.54.camel@thomas.amantes> <43AC2336.3030909@n-man.com> <1135355886.15650.68.camel@thomas.amantes> <43AC34BE.6000304@n-man.com> Message-ID: <1135360140.31319.4.camel@localhost.localdomain> On Fri, 2005-12-23 at 11:32 -0600, Patrick Barnes wrote: > Elliot Lee wrote: > > On Fri, 23 Dec 2005, Thomas Vander Stichele wrote: > > > > > Just to make sure I follow you - this only applies to the binaries, > > > correct ? We both agree that patent law does not stop you from shipping > > > source code that implements patented techniques ? > > > > Even this is questionable. It depends a lot on what constitutes patent > > infringement. Wikipedia sez "In U.S. law, an infringement may occur where > > the defendant has made, used, sold, offered to sell, or imported the > > infringing invention or its equivalent." Because software patents, such as > > the MP3 ones, typically claim a "method by which X happens", the source > > code could be argued to be the equivalent of the invention described in > > the MP3 patents' claims. Form doesn't seem to be important in patent law, > > only function - see http://en.wikipedia.org/wiki/Doctrine_of_equivalents > > > > I think a lot of this discussion here consists of us trying to be patent > > lawyers when we're not. While free software hackers are generally much > > more aware of IP law than your average Joe, we're just missing too much > > knowledge of patent case law and general "legal flavor" to have any idea > > which way this goes, legally speaking. > > > > I expect there will be future developments in the media formats area of > > Fedora, but for now it seems unlikely that we will do more than link to > > the packages you have kindly made available. > > > > Best, > > -- Elliot > > Red Hat Summit Nashville (May 30 - June 2, 2006) > > http://www.redhat.com/promo/summit/ > > > > > While my view is that the patent would cover only the binary form, legal > precedent suggests that the patent also covers the source form. A fine > example of this would be the DVD decryption code - which has been deemed > illegal in U.S. courts. As far as Fedora is concerned, this is a moot > point. I can't think of any examples of entire packages that we > distribute only in source form. Packages that we cannot build and > distribute in binary form and that downstream cannot build and > distribute (without regard to contracts) have typically been excluded > and left to projects like Livna. The DVD decryption code is illegal due to DMCA restrictions, not patents. AFAIK no patent infringement issue has been raised to date regarding DeCSS. Even as non-lawyers, we still have to be careful not to muddy the waters in arguments about copyrights, patents, trademarks, DMCA, and other legal issues. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- 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 stickster at gmail.com Fri Dec 23 17:54:22 2005 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 23 Dec 2005 12:54:22 -0500 Subject: Royalty free gstreamer plug-in In-Reply-To: <604aa7910512230942q25651cbdqb121cf74d53537ab@mail.gmail.com> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <1135352741.15650.54.camel@thomas.amantes> <43AC2336.3030909@n-man.com> <1135355886.15650.68.camel@thomas.amantes> <604aa7910512230942q25651cbdqb121cf74d53537ab@mail.gmail.com> Message-ID: <1135360463.31319.9.camel@localhost.localdomain> On Fri, 2005-12-23 at 12:42 -0500, Jeff Spaleta wrote: > On 12/23/05, Elliot Lee wrote: > > I expect there will be future developments in the media formats area of > > Fedora, but for now it seems unlikely that we will do more than link to > > the packages you have kindly made available. > > Even being able to link to this software as a prefered legal means to > get mp3 support worth be a noteworthy change in the legal landscape. While you're certainly correct, I would still like to see a *real* step forward, which would be to fund a decoder for OGG with a significantly lower "horsepower" requirement that portable audio player hardware developers and vendors would be inclined to support. In the meantime, getting people to convert to OGG as the solution of choice for non-portable (and some portable) audio would be easier with this link available. If the Fedora community decides to support linking to the Fluendo plugin, IMHO we should make intentions clear in this respect. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- 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 at apestaart.org Fri Dec 23 18:13:28 2005 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Fri, 23 Dec 2005 19:13:28 +0100 Subject: Royalty free gstreamer plug-in In-Reply-To: <43AC2FA5.1030601@laposte.net> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <1135352741.15650.54.camel@thomas.amantes> <43AC2336.3030909@n-man.com> <604aa7910512230826u4c22d27ftdfb051dd1605da18@mail.gmail.com> <43AC2674.6060601@n-man.com> <604aa7910512230857j12d52d0eo52e25a0877b4a4da@mail.gmail.com> <43AC2FA5.1030601@laposte.net> Message-ID: <1135361609.15650.83.camel@thomas.amantes> Hi, > But you can do it (CentOS does) > That's the whole point. To be allowed to take Fedora Core and do > something else with it, if you disagree with Red Hat policies. > > This proposal OTOH is pretty much your take it or leave it traditional > closed software offer. Not really. CentOS can still rebuild the whole distro, without the mp3 plugin, or choose to enter into a distributor's agreement with Fluendo, and ship with the mp3 plugin. Also, when was the last time that in a traditional closed software offer you could see the source, make changes to it, submit the changes, and get legal use out of your changes by using the next version of the binary that gets released ? You're trying to paint it a lot more black and white than it is, I think. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> Bye bye long day need to sleep so much ninety hours straight <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From cmadams at hiwaay.net Fri Dec 23 18:38:43 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Fri, 23 Dec 2005 12:38:43 -0600 Subject: Royalty free gstreamer plug-in In-Reply-To: <43AC2CE1.5040400@redhat.com> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <1135352741.15650.54.camel@thomas.amantes> <43AC2336.3030909@n-man.com> <1135355886.15650.68.camel@thomas.amantes> <43AC2CE1.5040400@redhat.com> Message-ID: <20051223183843.GB1549677@hiwaay.net> Once upon a time, Rahul Sundaram said: > I am not sure about that. Even if everyone agrees on that here we still > might need to consult the legal team before proceeding with this. > Everyone here might reach a position that makes the obvious sense but > thats not necessary what the law says. So lets talk to the counsel and > halt the discussion for now. Red Hat has an inconsistent position on patents and source. For some things, the source is stripped of the code (so no more pristine source), but for others, the source shipped still includes the problem code (it just isn't compiled). - For MP3, the code is removed. - OpenSSH has the CSS code removed (which I guess is DMCA related not patent; it is also a pretty lame OpenSSH attempt to make a political "statement" by including undocumented, non-standard, and unneeded "features"). - OpenSSL has numerous patent bits removed from the source. This is a change; IIRC in the past it was just built without the patented bits enabled (they were still in the source). - NTFS code remains in the kernel source; the reason cited for not building it is patents. - Font bytecode interpreter is disabled in freetype but the code remains and the spec file even provides a build option to include it. From what I understand, it is not enabled due to patents. Why is it okay to ship the source to some things that are not used for patent reasons but not to ship the source to others? -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From sundaram at redhat.com Fri Dec 23 19:25:46 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Sat, 24 Dec 2005 00:55:46 +0530 Subject: Royalty free gstreamer plug-in In-Reply-To: <20051223183843.GB1549677@hiwaay.net> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <1135352741.15650.54.camel@thomas.amantes> <43AC2336.3030909@n-man.com> <1135355886.15650.68.camel@thomas.amantes> <43AC2CE1.5040400@redhat.com> <20051223183843.GB1549677@hiwaay.net> Message-ID: <43AC4F3A.1070702@redhat.com> Hi >Red Hat has an inconsistent position on patents and source. For some >things, the source is stripped of the code (so no more pristine source), >but for others, the source shipped still includes the problem code (it >just isn't compiled). > >- For MP3, the code is removed. > >- OpenSSH has the CSS code removed (which I guess is DMCA related not > patent; it is also a pretty lame OpenSSH attempt to make a political > "statement" by including undocumented, non-standard, and unneeded > "features"). > >- OpenSSL has numerous patent bits removed from the source. This is a > change; IIRC in the past it was just built without the patented bits > enabled (they were still in the source). > >- NTFS code remains in the kernel source; the reason cited for not > building it is patents. > >- Font bytecode interpreter is disabled in freetype but the code remains > and the spec file even provides a build option to include it. From > what I understand, it is not enabled due to patents. > >Why is it okay to ship the source to some things that are not used for >patent reasons but not to ship the source to others? > > Forwarded to the legal contact[1]. Thanks -- Rahul [1] http://fedora.redhat.com/About/contact.html From walovaton at yahoo.com.mx Fri Dec 23 20:17:03 2005 From: walovaton at yahoo.com.mx (William Lovaton) Date: Fri, 23 Dec 2005 14:17:03 -0600 (CST) Subject: VMWare tools on Fedora Core 5 Message-ID: <20051223201703.36602.qmail@web60717.mail.yahoo.com> Hello, I've been doing some testing of RawHide on a virutal machine I configured a few days ago with VMWare 5.5.1 build-19175. Every thing is working fine except that I can't install the VMWare tools on the guess operating system to improve performance and imrpove the display settings so I can use a decent resolution, right now am stuck with 800 x 600. Any idea about how to install the VMWare tools on FC5 guess OS? when I try to do it gnome-volume-manager crashes and it doesn't do anything, any attempt to restart g-v-m results in a immediate crash. The only way to fix it is to cancel the installation of the VMWare tools and then g-v-m can be started normally again. I hope it can be done because that performance gain would be great, all in all I am very impressed with FC5 performance. Cheers, -William ___________________________________________________________ Do You Yahoo!? La mejor conexi?n a Internet y 2GB extra a tu correo por $100 al mes. http://net.yahoo.com.mx From ivazquez at ivazquez.net Fri Dec 23 20:26:34 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 23 Dec 2005 15:26:34 -0500 Subject: VMWare tools on Fedora Core 5 In-Reply-To: <20051223201703.36602.qmail@web60717.mail.yahoo.com> References: <20051223201703.36602.qmail@web60717.mail.yahoo.com> Message-ID: <1135369594.1969.12.camel@ignacio.lan> On Fri, 2005-12-23 at 14:17 -0600, William Lovaton wrote: > I've been doing some testing of RawHide on a virutal > machine I configured a few days ago with VMWare 5.5.1 > build-19175. Every thing is working fine except that > I can't install the VMWare tools on the guess > operating system to improve performance and imrpove > the display settings so I can use a decent resolution, > right now am stuck with 800 x 600. > > Any idea about how to install the VMWare tools on FC5 > guess OS? when I try to do it gnome-volume-manager > crashes and it doesn't do anything, any attempt to > restart g-v-m results in a immediate crash. The only > way to fix it is to cancel the installation of the > VMWare tools and then g-v-m can be started normally > again. > > I hope it can be done because that performance gain > would be great, all in all I am very impressed with > FC5 performance. VMware doesn't provide a driver for X.org 7.0. It isn't needed though, as X.org already contains a FOSS driver for the VMware video card; you just need to select a better monitor in the Display properties. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 Fri Dec 23 20:36:33 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Fri, 23 Dec 2005 21:36:33 +0100 (CET) Subject: Royalty free gstreamer plug-in In-Reply-To: <1135361609.15650.83.camel@thomas.amantes> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <1135352741.15650.54.camel@thomas.amantes> <43AC2336.3030909@n-man.com> <604aa7910512230826u4c22d27ftdfb051dd1605da18@mail.gmail.com> <43AC2674.6060601@n-man.com> <604aa7910512230857j12d52d0eo52e25a0877b4a4da@mail.gmail.com> <43AC2FA5.1030601@laposte.net> <1135361609.15650.83.camel@thomas.amantes> Message-ID: <37989.81.64.157.3.1135370193.squirrel@rousalka.dyndns.org> On Ven 23 d?cembre 2005 19:13, Thomas Vander Stichele wrote: > Also, when was the last time that in a traditional closed software offer > you could see the source, make changes to it, submit the changes, and > get legal use out of your changes by using the next version of the > binary that gets released ? > > You're trying to paint it a lot more black and white than it is, I > think. This is a lot less exceptional than you think. Microsoft shared source program is pretty much the same thing. Here only upstream is allowed to release legit binaries, so you don't get the vendor freedom real FOSS permits. The point of pure FOSS distros like FC is they're not benevolent dictatorships. You don't like them you can leave them taking with you 100% of the code and associated rebuild rights. As you admitted yourself a Centos-like effort would have to drop the mp3 plugin. So it's definitely not free (I'll grant you the open part) -- Nicolas Mailhot From mpeters at mac.com Fri Dec 23 20:48:56 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 23 Dec 2005 12:48:56 -0800 Subject: Royalty free gstreamer plug-in In-Reply-To: <1135348143.15650.34.camel@thomas.amantes> References: <43ABF07B.6060101@redhat.com> <43ABF704.4070109@nicubunu.ro> <43ABF78F.7000506@redhat.com> <1135348143.15650.34.camel@thomas.amantes> Message-ID: <1135370936.7522.5.camel@locolhost.localdomain> On Fri, 2005-12-23 at 15:29 +0100, Thomas Vander Stichele wrote: > On Fri, 2005-12-23 at 18:41 +0530, Rahul Sundaram wrote: > > Hi > > > > > > > > On the positive side, I think Fedora is allowed now to write in FAQ or > > > release notes: "to play mp3 files, go to this specific Fluendo page, > > > click and install the rpm" > > > > > We could have done that with RealPlayer long before. We dont do that > > since we dont support proprietary formats. If you want a Free software > > platform be prepared to support and use a Free and superior format like > > Ogg. Thats my take on it. > > I think that's a great and courageous statement to make. The reason > we're giving away this plug-in, legally, is because we feel users and > distributions should be given the choice to allow their users to migrate > from closed to open formats. Not to mention there are very few portable players that support ogg. Support for mp3 in portable players is everywhere. I'm very excited about this - it would be really nice if Red Hat was able to purchase a distribution license - assuming that there would be no issues of third parties continuing to distribute official (sha1sum matching) iso's. From jspaleta at gmail.com Fri Dec 23 20:59:13 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 23 Dec 2005 15:59:13 -0500 Subject: Royalty free gstreamer plug-in In-Reply-To: <1135361609.15650.83.camel@thomas.amantes> References: <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <1135352741.15650.54.camel@thomas.amantes> <43AC2336.3030909@n-man.com> <604aa7910512230826u4c22d27ftdfb051dd1605da18@mail.gmail.com> <43AC2674.6060601@n-man.com> <604aa7910512230857j12d52d0eo52e25a0877b4a4da@mail.gmail.com> <43AC2FA5.1030601@laposte.net> <1135361609.15650.83.camel@thomas.amantes> Message-ID: <604aa7910512231259j67248718rc990104aff6c2df4@mail.gmail.com> On 12/23/05, Thomas Vander Stichele wrote: > Also, when was the last time that in a traditional closed software offer > you could see the source, make changes to it, submit the changes, and > get legal use out of your changes by using the next version of the > binary that gets released ? As i've mentioned elsewhere... the inability to patch as needed downstream without upstream authorization is probably a deal breaker without invoking the rights of downstream rebuilders who want to use Fedora sources. A Fedora maintainer would need to have the flexibility and authority to patch for security/compatibility on a timescale faster than upstream might be able to respond. A requirement for any patches to be submitted back to upstream isn't unreasonable to me. But having to wait for upstream to formally bless them and re-incorporate them is going to be a maintenance burden. This I believe is one of problems which keeps pine out of Fedora. -jef From mpeters at mac.com Fri Dec 23 21:03:02 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 23 Dec 2005 13:03:02 -0800 Subject: Royalty free gstreamer plug-in In-Reply-To: <43AC3562.5000103@n-man.com> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <604aa7910512230752p5f506333se69a4171abf6c811@mail.gmail.com> <43AC2534.2090903@n-man.com> <604aa7910512230830q22353473xa38f3e682dc01bfc@mail.gmail.com> <43AC3562.5000103@n-man.com> Message-ID: <1135371783.7522.11.camel@locolhost.localdomain> On Fri, 2005-12-23 at 11:35 -0600, Patrick Barnes wrote: > Jeff Spaleta wrote: > > On 12/23/05, Patrick Barnes wrote: > > > Also, this solution is GPL-incompatible, meaning we > > > can't integrate this plugin with GPL software. > > > > who cares.... we have lots of GPL incompatible code in Fedora. I don't > > even know why you bring this up. gst is LGPL and we are talking about > > a runtime detected plugin to gst. > > > > -jef > > > > > This affects the players, too. Theoretically, by law, we could not use > this plugin with Rhythmbox, but we could with Totem. Rhythmbox uses gstreamer, it would be gstreamer that uses the plugin. Rhythmbox does not link against the plugin, does not require the plugin, etc. For that matter - neither does gstreamer. I don't think there would be a legal problem. If there was - can I use my X11 server which is MIT to display an emacs window? What about emacs opening an X11 window? I don't see a difference between that and rhythmbox using gstreamer (lgp) which talks to this plugin. From mharris at mharris.ca Fri Dec 23 21:09:19 2005 From: mharris at mharris.ca (Mike A. Harris) Date: Fri, 23 Dec 2005 16:09:19 -0500 Subject: VMWare tools on Fedora Core 5 In-Reply-To: <1135369594.1969.12.camel@ignacio.lan> References: <20051223201703.36602.qmail@web60717.mail.yahoo.com> <1135369594.1969.12.camel@ignacio.lan> Message-ID: <43AC677F.4080501@mharris.ca> Ignacio Vazquez-Abrams wrote: > On Fri, 2005-12-23 at 14:17 -0600, William Lovaton wrote: > >>I've been doing some testing of RawHide on a virutal >>machine I configured a few days ago with VMWare 5.5.1 >>build-19175. Every thing is working fine except that >>I can't install the VMWare tools on the guess >>operating system to improve performance and imrpove >>the display settings so I can use a decent resolution, >>right now am stuck with 800 x 600. >> >>Any idea about how to install the VMWare tools on FC5 >>guess OS? when I try to do it gnome-volume-manager >>crashes and it doesn't do anything, any attempt to >>restart g-v-m results in a immediate crash. The only >>way to fix it is to cancel the installation of the >>VMWare tools and then g-v-m can be started normally >>again. >> >>I hope it can be done because that performance gain >>would be great, all in all I am very impressed with >>FC5 performance. > > > VMware doesn't provide a driver for X.org 7.0. It isn't needed though, > as X.org already contains a FOSS driver for the VMware video card; you > just need to select a better monitor in the Display properties. Actually, VMware Inc. maintains the 'vmware' video driver that is in X.Org. It is the official X 'vmware' driver. If users have problems with this driver, please report them to X.Org bugzilla in the proper component, so that the VMware Inc. engineer(s) who maintain the driver are aware of the problem. The VMware guys have done a good job of maintaining the driver, and commit changes to CVS on a frequent enough basis that I'd consider it to be well maintained personally. The VMware software probably includes a vmware X driver also, as all users out there may or may not have the latest driver for a given X release, and they probably prefer it if users use the latest driver than perhaps an older one that came with their OS which may not have the latest bug fixes and features, etc. For Fedora users, I would recommend using the driver that ships with Fedora, and filing bugs in Xorg bugzilla if problems arise. If there are bugs in the driver, we can always patch it to be on par with whatever the driver is that vmware ships with their product, as it is the same driver as is in CVS head as far as I am aware. Hope this helps. -- Mike A. Harris, Open Source Advocate * http://mharris.ca Proud to be Canadian. From stickster at gmail.com Fri Dec 23 21:21:15 2005 From: stickster at gmail.com (Paul W. Frields) Date: Fri, 23 Dec 2005 16:21:15 -0500 Subject: VMWare tools on Fedora Core 5 In-Reply-To: <1135369594.1969.12.camel@ignacio.lan> References: <20051223201703.36602.qmail@web60717.mail.yahoo.com> <1135369594.1969.12.camel@ignacio.lan> Message-ID: <1135372875.15202.17.camel@localhost.localdomain> On Fri, 2005-12-23 at 15:26 -0500, Ignacio Vazquez-Abrams wrote: > On Fri, 2005-12-23 at 14:17 -0600, William Lovaton wrote: > > I've been doing some testing of RawHide on a virutal > > machine I configured a few days ago with VMWare 5.5.1 > > build-19175. Every thing is working fine except that > > I can't install the VMWare tools on the guess > > operating system to improve performance and imrpove > > the display settings so I can use a decent resolution, > > right now am stuck with 800 x 600. > > > > Any idea about how to install the VMWare tools on FC5 > > guess OS? when I try to do it gnome-volume-manager > > crashes and it doesn't do anything, any attempt to > > restart g-v-m results in a immediate crash. The only > > way to fix it is to cancel the installation of the > > VMWare tools and then g-v-m can be started normally > > again. > > > > I hope it can be done because that performance gain > > would be great, all in all I am very impressed with > > FC5 performance. > > VMware doesn't provide a driver for X.org 7.0. It isn't needed though, > as X.org already contains a FOSS driver for the VMware video card; you > just need to select a better monitor in the Display properties. I was under the impression that the VMWare tools also include support for DMA to hard disk, which drops the CPU load considerably on my box, and also better networking support in the pcnet32 driver. (I am only running 5.5.0 right now, so I don't know about 5.5.1.) I don't know how to solve the g-v-m problem; I manually mounted the CD instead to install the tools, and restarted g-v-m after installing the tools. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- 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 walovaton at yahoo.com.mx Fri Dec 23 21:49:47 2005 From: walovaton at yahoo.com.mx (William Lovaton) Date: Fri, 23 Dec 2005 15:49:47 -0600 (CST) Subject: VMWare tools on Fedora Core 5 In-Reply-To: <1135372875.15202.17.camel@localhost.localdomain> Message-ID: <20051223214947.63713.qmail@web60718.mail.yahoo.com> --- "Paul W. Frields" escribi?: > I was under the impression that the VMWare tools > also include support > for DMA to hard disk, which drops the CPU load > considerably on my box, > and also better networking support in the pcnet32 > driver. (I am only > running 5.5.0 right now, so I don't know about > 5.5.1.) I don't know how > to solve the g-v-m problem; I manually mounted the > CD instead to install > the tools, and restarted g-v-m after installing the > tools. Hi Paul, So you managed to install the tools? How did that go? is it working good for you? did you see any indication of the progress? I just see that g-v-m crashes but other than that I don't see that VMWare tool are being installed... did you get some feedback on your screen or something? did you get a confirmation message that the tool were installed ok? Thanx, -William ___________________________________________________________ Do You Yahoo!? La mejor conexi?n a Internet y 2GB extra a tu correo por $100 al mes. http://net.yahoo.com.mx From tmus at tmus.dk Fri Dec 23 22:19:39 2005 From: tmus at tmus.dk (Thomas M Steenholdt) Date: Fri, 23 Dec 2005 23:19:39 +0100 Subject: VMWare tools on Fedora Core 5 In-Reply-To: <20051223214947.63713.qmail@web60718.mail.yahoo.com> References: <1135372875.15202.17.camel@localhost.localdomain> <20051223214947.63713.qmail@web60718.mail.yahoo.com> Message-ID: William Lovaton wrote: > So you managed to install the tools? How did that go? > is it working good for you? did you see any indication > of the progress? I just see that g-v-m crashes but > other than that I don't see that VMWare tool are being > installed... did you get some feedback on your screen > or something? did you get a confirmation message that > the tool were installed ok? > You guys could try the latest vmware-any-any patches from http://ftp.cvut.cz/vmware/ to see if that solves your issues. Whatever issue could easily be related to selinux, gcc stack protection or some other thing and the any-any patches tries to take care of weird situation like this. That said, i did not try installing FC5test under VMware workstation. The way to install tools in a linux guest, IMHO, is selecting "install vmware tools", mount the cd in the guest, untgz and build the tools. That should take care of the entire thing. Hope this helps /Thomas From walovaton at yahoo.com.mx Fri Dec 23 22:26:51 2005 From: walovaton at yahoo.com.mx (William Lovaton) Date: Fri, 23 Dec 2005 16:26:51 -0600 (CST) Subject: VMWare tools on Fedora Core 5 In-Reply-To: <43AC677F.4080501@mharris.ca> Message-ID: <20051223222651.25061.qmail@web60720.mail.yahoo.com> Hi Mike, thanx a lot for your comments, Now I changed my monitor setting so a I can use a resolution of 1024 x 768 which is what my host system can give. But I discovered a little bug in system-config-display. Whenever I try to change the Video Card setting in s-c-d, I don't get any window, but got this in console (pushing the "Configure" button in s-c-d): Traceback (most recent call last): File "/usr/share/system-config-display/xConfigDialog.py", line 345, in configure_videocard self.state) File "/usr/share/system-config-display/videocardDialog.py", line 63, in __init__ selection.select_iter(videocard_store.get_iter_first()) TypeError: iter should be a GtkTreeIter May be I should search in redhat's bugzilla and see if it have been reported. Do you know something about this problem? Thanx to all of you, I now can use a decent resolution without installing the VMWare tools. However, in Windows you can use your mouse without any hassle since VMWare grabs the input any time the window gets the focus, with linux you have to click (or Ctrl + G) and Ctrl + Alt to grab/release the focus which is a little annoying. Cheers, -William --- "Mike A. Harris" escribi?: > Actually, VMware Inc. maintains the 'vmware' video > driver that > is in X.Org. It is the official X 'vmware' driver. > If users > have problems with this driver, please report them > to X.Org > bugzilla in the proper component, so that the VMware > Inc. > engineer(s) who maintain the driver are aware of the > problem. > > The VMware guys have done a good job of maintaining > the driver, > and commit changes to CVS on a frequent enough basis > that I'd > consider it to be well maintained personally. > > The VMware software probably includes a vmware X > driver also, > as all users out there may or may not have the > latest driver > for a given X release, and they probably prefer it > if users > use the latest driver than perhaps an older one that > came with > their OS which may not have the latest bug fixes and > features, > etc. > > For Fedora users, I would recommend using the driver > that ships > with Fedora, and filing bugs in Xorg bugzilla if > problems arise. > If there are bugs in the driver, we can always patch > it to be > on par with whatever the driver is that vmware ships > with their > product, as it is the same driver as is in CVS head > as far as > I am aware. > > Hope this helps. > > -- > Mike A. Harris, Open Source Advocate * > http://mharris.ca > Proud to be Canadian. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > ___________________________________________________________ Do You Yahoo!? La mejor conexi?n a Internet y 2GB extra a tu correo por $100 al mes. http://net.yahoo.com.mx From ivazquez at ivazquez.net Fri Dec 23 22:42:57 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Fri, 23 Dec 2005 17:42:57 -0500 Subject: VMWare tools on Fedora Core 5 In-Reply-To: <20051223222651.25061.qmail@web60720.mail.yahoo.com> References: <20051223222651.25061.qmail@web60720.mail.yahoo.com> Message-ID: <1135377777.1969.19.camel@ignacio.lan> On Fri, 2005-12-23 at 16:26 -0600, William Lovaton wrote: > However, in Windows you can use your mouse without any > hassle since VMWare grabs the input any time the > window gets the focus, with linux you have to click > (or Ctrl + G) and Ctrl + Alt to grab/release the focus > which is a little annoying. FTR, I did manage to get vmware-tools built on 5.0 (sans video driver, of course), but g-v-m keeps crashing. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 Fri Dec 23 22:46:02 2005 From: hughsient at gmail.com (Richard Hughes) Date: Fri, 23 Dec 2005 22:46:02 +0000 Subject: VMWare tools on Fedora Core 5 In-Reply-To: <1135377777.1969.19.camel@ignacio.lan> References: <20051223222651.25061.qmail@web60720.mail.yahoo.com> <1135377777.1969.19.camel@ignacio.lan> Message-ID: <1135377962.27617.0.camel@localhost> On Fri, 2005-12-23 at 17:42 -0500, Ignacio Vazquez-Abrams wrote: > On Fri, 2005-12-23 at 16:26 -0600, William Lovaton wrote: > > However, in Windows you can use your mouse without any > > hassle since VMWare grabs the input any time the > > window gets the focus, with linux you have to click > > (or Ctrl + G) and Ctrl + Alt to grab/release the focus > > which is a little annoying. > > FTR, I did manage to get vmware-tools built on 5.0 (sans video driver, > of course), but g-v-m keeps crashing. Me too. I can't get any debug information out of g-v-m either (and strace and gdb are not being helpful) -- any ideas? Richard. From mharris at mharris.ca Sat Dec 24 01:31:30 2005 From: mharris at mharris.ca (Mike A. Harris) Date: Fri, 23 Dec 2005 20:31:30 -0500 Subject: VMWare tools on Fedora Core 5 In-Reply-To: <20051223222651.25061.qmail@web60720.mail.yahoo.com> References: <20051223222651.25061.qmail@web60720.mail.yahoo.com> Message-ID: <43ACA4F2.7040609@mharris.ca> William Lovaton wrote: > Traceback (most recent call last): > File > "/usr/share/system-config-display/xConfigDialog.py", > line 345, in configure_videocard > self.state) > File > "/usr/share/system-config-display/videocardDialog.py", > line 63, in __init__ > > selection.select_iter(videocard_store.get_iter_first()) > TypeError: iter should be a GtkTreeIter > > May be I should search in redhat's bugzilla and see if > it have been reported. > > Do you know something about this problem? system-config-display is maintained by other people, I don't really follow it very closely, and tend to just do "s-c-d --reconfig" then hand edit the results manually thereafter myself. If it's not in bugzilla already, it's probably worth reporting though. HTH -- Mike A. Harris, Open Source Advocate * http://mharris.ca Proud to be Canadian. From bojan at rexursive.com Sat Dec 24 02:01:37 2005 From: bojan at rexursive.com (Bojan Smojver) Date: Sat, 24 Dec 2005 13:01:37 +1100 Subject: Random X crashes: fact or fiction? Message-ID: <1135389697.9996.5.camel@coyote.rexursive.com> As of about 2-3 weeks ago, I'm seeing random crashes of X under heavy load (e.g. kernel compile in an xterm, Firefox, Evolution being started etc. - all under Gnome). X simply dies and I end up on VT1, after which X gets restarted (i.e. GDM). Obviously, all the processes running inside X die too. This is with up-to-date Rawhide in i686 with Radeon IGP M340. The most recent crash was during kernel compile this morning, with all the recent packages. Before I start digging around trying to figure out how to report this for real, just wanted to check if there are other people that have observed similar stuff with recent X. Just making sure I'm not going crazy here... -- Bojan From idht4n at hotmail.com Sat Dec 24 02:42:09 2005 From: idht4n at hotmail.com (David L) Date: Fri, 23 Dec 2005 18:42:09 -0800 Subject: Palm sync status? Message-ID: Hi, I just bought a Treo 650 and was looking for info about how to use it with FC4 when I found a posting which says FC4 is "completely broken with respect to Palm syncronization". Is this supposed to be addressed in FC5, or should I "downgrade" to FC3? Has anybody synced a Treo with Evolution in FC5-test1? I asked this message on fedora-list and somebody responded saying that there was a discussion on this list. But I haven't been able to find anything definitive that says whether FC5 is supposed to fix the FC4 syncing problems. Does anyone know? Will I be able to sync a Treo 650 with evolution? Thanks... David _________________________________________________________________ Don?t just search. Find. Check out the new MSN Search! http://search.msn.click-url.com/go/onm00200636ave/direct/01/ From dragoran at feuerpokemon.de Sat Dec 24 08:34:48 2005 From: dragoran at feuerpokemon.de (dragoran) Date: Sat, 24 Dec 2005 09:34:48 +0100 Subject: how does selinux get initialized durring bootup? Message-ID: <43AD0828.5060605@feuerpokemon.de> as you can see here: http://bugzilla.initng.thinktux.net/show_bug.cgi?id=365 there is a bug in initng that after booting selinux is not working. what needs to be done in the boot process to get selinux working ? have searched in the initscripts and have'nt found anything that helps. From florin at andrei.myip.org Sat Dec 24 08:35:25 2005 From: florin at andrei.myip.org (Florin Andrei) Date: Sat, 24 Dec 2005 00:35:25 -0800 Subject: Palm sync status? In-Reply-To: References: Message-ID: <1135413325.3721.2.camel@rivendell.home.local> On Fri, 2005-12-23 at 18:42 -0800, David L wrote: > > I just bought a Treo 650 and was looking for info about how to use it with > FC4 when I found a posting which says FC4 is "completely broken with respect > to Palm syncronization". Is this supposed to be addressed in FC5, or should > I "downgrade" to FC3? My Handspring Visor Platinum works with JPilot on FC4 provided that I manually create the /dev/ttyUSB* files before each synchronization. Yeah, it's broken. -- Florin Andrei http://florin.myip.org/ From dwmw2 at infradead.org Sat Dec 24 11:58:18 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 24 Dec 2005 11:58:18 +0000 Subject: Too much time wasted installing fedora on raid1 In-Reply-To: <20051222143334.GA27272@devserv.devel.redhat.com> References: <20051219201653.GU1556@stingr.net> <1135026753.2947.23.camel@laptopd505.fenrus.org> <20051220085657.GW1556@stingr.net> <1135071978.2952.8.camel@laptopd505.fenrus.org> <20051220101303.GB23000@ryoko.camperquake.de> <1135073956.2952.10.camel@laptopd505.fenrus.org> <1135082117.3154.5.camel@localhost.localdomain> <20051222112517.GA3648@devserv.devel.redhat.com> <1135252544.3557.19.camel@pmac.infradead.org> <20051222143334.GA27272@devserv.devel.redhat.com> Message-ID: <1135425498.4130.34.camel@pmac.infradead.org> On Thu, 2005-12-22 at 09:33 -0500, Alan Cox wrote: > You need to learn the difference between a design flaw and pragmatic > design. It varies, but normally it's somewhere between three and seven years in my experience. :) -- dwmw2 From stickster at gmail.com Sat Dec 24 13:41:00 2005 From: stickster at gmail.com (Paul W. Frields) Date: Sat, 24 Dec 2005 08:41:00 -0500 Subject: VMWare tools on Fedora Core 5 In-Reply-To: References: <1135372875.15202.17.camel@localhost.localdomain> <20051223214947.63713.qmail@web60718.mail.yahoo.com> Message-ID: <1135431660.5814.8.camel@localhost.localdomain> On Fri, 2005-12-23 at 23:19 +0100, Thomas M Steenholdt wrote: > William Lovaton wrote: > > So you managed to install the tools? How did that go? > > is it working good for you? did you see any indication > > of the progress? I just see that g-v-m crashes but > > other than that I don't see that VMWare tool are being > > installed... did you get some feedback on your screen > > or something? did you get a confirmation message that > > the tool were installed ok? > > > > You guys could try the latest vmware-any-any patches from > http://ftp.cvut.cz/vmware/ to see if that solves your issues. Whatever > issue could easily be related to selinux, gcc stack protection or some > other thing and the any-any patches tries to take care of weird > situation like this. That said, i did not try installing FC5test under > VMware workstation. Exactly so, WRT to the vmware-any-any patches. I used them throughout FC4 with VMWare 5.0 to great results. > The way to install tools in a linux guest, IMHO, is selecting "install > vmware tools", mount the cd in the guest, untgz and build the tools. > That should take care of the entire thing. Actually, I installed the RPM, which I would consider preferable in an RPM-based distro. ;-) Works just as well: 1. Mount CD manually (mount /media/cdrom) 2. run: su -c 'rpm -ivh /media/cdrom/VMWare*rpm' (you can't use yum because the RPM is not signed -- this is not a big deal since the package from whence the CD files come is, itself, signed) 3. run: su -c 'vmware-config-tools.pl' (need kernel-devel and gcc installed) -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- 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 stickster at gmail.com Sat Dec 24 13:46:58 2005 From: stickster at gmail.com (Paul W. Frields) Date: Sat, 24 Dec 2005 08:46:58 -0500 Subject: Palm sync status? In-Reply-To: <1135413325.3721.2.camel@rivendell.home.local> References: <1135413325.3721.2.camel@rivendell.home.local> Message-ID: <1135432018.5814.14.camel@localhost.localdomain> On Sat, 2005-12-24 at 00:35 -0800, Florin Andrei wrote: > On Fri, 2005-12-23 at 18:42 -0800, David L wrote: > > > > I just bought a Treo 650 and was looking for info about how to use it with > > FC4 when I found a posting which says FC4 is "completely broken with respect > > to Palm syncronization". Is this supposed to be addressed in FC5, or should > > I "downgrade" to FC3? > > My Handspring Visor Platinum works with JPilot on FC4 provided that I > manually create the /dev/ttyUSB* files before each synchronization. > > Yeah, it's broken. I fixed this problem some time ago, IIRC, by simply adding a file "/etc/udev/rules.d/95-visor.rules" that has just this line: KERNEL="ttyUSB1",SYMLINK="pilot" HTH... If not, I'm sure if you check Bugzilla you'll find the answer. I should note my wife uses a Sony Clie and not a Treo, but if your Treo syncs on ttyUSB1, this will work. Otherwise, just alter the KERNEL parameter appropriately. If you leave the symlink name as "pilot" you won't have to fiddle as much with the gnome-pilot stuff. In the future, shouldn't these issues go to fedora-list and not fedora-devel-list? -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From paul at permanentmail.com Sat Dec 24 14:03:43 2005 From: paul at permanentmail.com (Paul Dickson) Date: Sat, 24 Dec 2005 07:03:43 -0700 Subject: VMWare tools on Fedora Core 5 In-Reply-To: <43ACA4F2.7040609@mharris.ca> References: <20051223222651.25061.qmail@web60720.mail.yahoo.com> <43ACA4F2.7040609@mharris.ca> Message-ID: <20051224070343.d68c6a46.paul@permanentmail.com> On Fri, 23 Dec 2005 20:31:30 -0500, Mike A. Harris wrote: > William Lovaton wrote: > > Traceback (most recent call last): > > File > > "/usr/share/system-config-display/xConfigDialog.py", > > line 345, in configure_videocard > > self.state) > > File > > "/usr/share/system-config-display/videocardDialog.py", > > line 63, in __init__ > > > > selection.select_iter(videocard_store.get_iter_first()) > > TypeError: iter should be a GtkTreeIter > > > > May be I should search in redhat's bugzilla and see if > > it have been reported. > > > > Do you know something about this problem? > > system-config-display is maintained by other people, I don't really > follow it very closely, and tend to just do "s-c-d --reconfig" then > hand edit the results manually thereafter myself. > > If it's not in bugzilla already, it's probably worth reporting though. It's in there twice: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176289 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172036 -Paul From ivazquez at ivazquez.net Sat Dec 24 14:11:26 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Sat, 24 Dec 2005 09:11:26 -0500 Subject: VMWare tools on Fedora Core 5 In-Reply-To: <1135431660.5814.8.camel@localhost.localdomain> References: <1135372875.15202.17.camel@localhost.localdomain> <20051223214947.63713.qmail@web60718.mail.yahoo.com> <1135431660.5814.8.camel@localhost.localdomain> Message-ID: <1135433486.1969.22.camel@ignacio.lan> On Sat, 2005-12-24 at 08:41 -0500, Paul W. Frields wrote: > On Fri, 2005-12-23 at 23:19 +0100, Thomas M Steenholdt wrote: > > William Lovaton wrote: > > > So you managed to install the tools? How did that go? > > > is it working good for you? did you see any indication > > > of the progress? I just see that g-v-m crashes but > > > other than that I don't see that VMWare tool are being > > > installed... did you get some feedback on your screen > > > or something? did you get a confirmation message that > > > the tool were installed ok? > > > > > > > You guys could try the latest vmware-any-any patches from > > http://ftp.cvut.cz/vmware/ to see if that solves your issues. Whatever > > issue could easily be related to selinux, gcc stack protection or some > > other thing and the any-any patches tries to take care of weird > > situation like this. That said, i did not try installing FC5test under > > VMware workstation. > > Exactly so, WRT to the vmware-any-any patches. I used them throughout > FC4 with VMWare 5.0 to great results. That's for when Fedora is the host. The situation described above is when Rawhide is the guest. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 gianluca.cecchi at gmail.com Sat Dec 24 14:57:36 2005 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Sat, 24 Dec 2005 15:57:36 +0100 Subject: fsck after crash not active in fc5 dev? Message-ID: <561c252c0512240657q5ef59948m@mail.gmail.com> Hello, I noticed after a crash (due to loss of electricity) that file systems was not asked to be fscked after reboot. The file /.autofsck is created at boot, as before, but comparing rh el 4 with fc5 it seemes that inside rc.sysinit the piece below is missing, so that the system does not prompt if one wants to force fsck and one has to manually create /forcefsck and reboot in this case (or probably is there a boot flag to tell to force fsck? I don't know this). if [ "$PROMPT" != "no" ]; then if [ "$AUTOFSCK_DEF_CHECK" = "yes" ]; then if /sbin/getkey -c $AUTOFSCK_TIMEOUT -m $"Press N within %d seconds to not force file system integrity check..." n ; then AUTOFSCK_OPT= fi else if /sbin/getkey -c $AUTOFSCK_TIMEOUT -m $"Press Y within %d seconds to force file system integrity check..." y ; then AUTOFSCK_OPT=-f fi fi echo else # PROMPT not allowed if [ "$AUTOFSCK_DEF_CHECK" = "yes" ]; then echo $"Forcing file system integrity check due to default setting" else echo $"Not forcing file system integrity check due to default setting" fi fi I'm testing fedora right now and don't know previous versions, so this could also be standard policy for fedora. Sorry in this case. Is this ok, due to devel os or did it disappear uncorrectly? I would like to have this chance also for devel/test systems. Just my opinion. Thanks for reading. Gianluca -------------- next part -------------- An HTML attachment was scrubbed... URL: From avi at argo.co.il Sat Dec 24 16:26:06 2005 From: avi at argo.co.il (Avi Kivity) Date: Sat, 24 Dec 2005 18:26:06 +0200 Subject: Too much time wasted installing fedora on raid1 In-Reply-To: <20051220134526.GZ1556@stingr.net> References: <20051219201653.GU1556@stingr.net> <1135026753.2947.23.camel@laptopd505.fenrus.org> <20051220085657.GW1556@stingr.net> <1135071978.2952.8.camel@laptopd505.fenrus.org> <20051220101303.GB23000@ryoko.camperquake.de> <1135073956.2952.10.camel@laptopd505.fenrus.org> <1135082117.3154.5.camel@localhost.localdomain> <36717.192.54.193.25.1135083965.squirrel@rousalka.dyndns.org> <1135084820.4066.31.camel@pmac.infradead.org> <20051220134526.GZ1556@stingr.net> Message-ID: <43AD769E.8020802@argo.co.il> Paul P Komkoff Jr wrote: >Replying to David Woodhouse: > > >>RAID is just a hack which hides the redundancy from the file system; the >>kind of thing we always used to have to do for DOS compatibility so that >>we could provide an INT 13h handler and have it 'just work'. It's much >>the same reasoning which led to the built-in 'translation layers' on >>cheap CF cards and USB sticks which so often eat your data and which >>have a tendency to use up their limited lifetime in copying obsolete >>sectors belonging to deleted files around on the underlying medium. >> >>We don't _need_ that kind of layering in Linux. Have a library of >>functions which can be used for such redundancy, by all means -- but >>don't just make RAID pretend to be a 'standard' block device and prevent >>all possibility of sharing knowledge between the file system and the >>layer providing the redundancy. That's just insane. >> >> > >Well, everything you said habove is correct. But I've yet seen any >"redundant block device filesystem" project anywhere. > > Sun zfs, Isilon OneFS, possibly others. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. From seandarcy2 at gmail.com Sun Dec 25 00:36:48 2005 From: seandarcy2 at gmail.com (sean darcy) Date: Sat, 24 Dec 2005 16:36:48 -0800 Subject: udev makes /dev/raw1394, but no module Message-ID: I've been setting up dvgrab to get some dv off my camcorder. I kept getting an error message raw1394: no such device. But /dev/raw1394 did exist, as did dv1394. The problem was that neither the raw1394 nor dv1394 modules were loaded. udev should be loading the modules, correct? But why is it creating the /dev entries if it's not loading the modules? Is this a feature, or a bug? Does udev only create the dev entries, and the user is supposed to load the modules? sean From zaitcev at redhat.com Sun Dec 25 00:55:46 2005 From: zaitcev at redhat.com (Pete Zaitcev) Date: Sat, 24 Dec 2005 16:55:46 -0800 Subject: Palm sync status? In-Reply-To: <1135432018.5814.14.camel@localhost.localdomain> References: <1135413325.3721.2.camel@rivendell.home.local> <1135432018.5814.14.camel@localhost.localdomain> Message-ID: <20051224165546.7fab755f.zaitcev@redhat.com> On Sat, 24 Dec 2005 08:46:58 -0500, "Paul W. Frields" wrote: > > My Handspring Visor Platinum works with JPilot on FC4 provided that I > > manually create the /dev/ttyUSB* files before each synchronization. > I fixed this problem some time ago, IIRC, by simply adding a file > "/etc/udev/rules.d/95-visor.rules" that has just this line: > > KERNEL="ttyUSB1",SYMLINK="pilot" This seems to be a different problem, unless the other guy is not seriously mistaken. In his case the original device nodes were not created. > In the future, shouldn't these issues go to fedora-list and not > fedora-devel-list? If we were talking about a proposed patch for udev, it would belong here. I keep the hope. There would also be a significant development content if we dicussed how to find a Pilot in a more robust way with udev. The thing is, we cannot ship KERNEL="ttyUSB1", because of dynamic numbering. -- Pete From zaitcev at redhat.com Sun Dec 25 00:58:13 2005 From: zaitcev at redhat.com (Pete Zaitcev) Date: Sat, 24 Dec 2005 16:58:13 -0800 Subject: udev makes /dev/raw1394, but no module In-Reply-To: References: Message-ID: <20051224165813.009ef0b0.zaitcev@redhat.com> On Sat, 24 Dec 2005 16:36:48 -0800, sean darcy wrote: > udev should be loading the modules, correct? But why is it creating the > /dev entries if it's not loading the modules? Is this a feature, or a > bug? Does udev only create the dev entries, and the user is supposed to > load the modules? Most likely the modules fail the initialization and return from their probe() with an error. -- Pete From walovaton at yahoo.com.mx Sun Dec 25 01:27:30 2005 From: walovaton at yahoo.com.mx (William Lovaton) Date: Sat, 24 Dec 2005 20:27:30 -0500 Subject: VMWare tools on Fedora Core 5 In-Reply-To: <1135433486.1969.22.camel@ignacio.lan> References: <1135372875.15202.17.camel@localhost.localdomain> <20051223214947.63713.qmail@web60718.mail.yahoo.com> <1135431660.5814.8.camel@localhost.localdomain> <1135433486.1969.22.camel@ignacio.lan> Message-ID: <1135474050.3119.35.camel@athlon2000> Exactly, this is the case, Rawhide is the guest OS. The Host is a Fedora Core 3 system. But I'm a little confused, some of you have been talking about that a CD is necessary to configure the VMWare tools. I just downloaded and installed the RPM from the VMWare web site, in my case there is no CD. And Paul mentioned something about vmware-config-tools.pl but I really can't find it, it is not installed on my system. As far as I can understand there is some kind of process (that I don't know anything about) that needs to be done in the guess OS in order to install the VMWare tools, can someone please enlighten me? Cheers, -William El s??b, 24-12-2005 a las 09:11 -0500, Ignacio Vazquez-Abrams escribi??: > That's for when Fedora is the host. The situation described above is > when Rawhide is the guest. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ?gratis! Reg?strate ya - http://correo.yahoo.com.mx/ From walovaton at yahoo.com.mx Sun Dec 25 00:56:14 2005 From: walovaton at yahoo.com.mx (William Lovaton) Date: Sat, 24 Dec 2005 19:56:14 -0500 Subject: VMWare tools on Fedora Core 5 In-Reply-To: <20051224070343.d68c6a46.paul@permanentmail.com> References: <20051223222651.25061.qmail@web60720.mail.yahoo.com> <43ACA4F2.7040609@mharris.ca> <20051224070343.d68c6a46.paul@permanentmail.com> Message-ID: <1135472175.3119.22.camel@athlon2000> Great, I'll comment on them, but those bug reports need to get some attention from the respective maintainer. Thanks, -William El s??b, 24-12-2005 a las 07:03 -0700, Paul Dickson escribi??: > On Fri, 23 Dec 2005 20:31:30 -0500, Mike A. Harris wrote: > > system-config-display is maintained by other people, I don't really > > follow it very closely, and tend to just do "s-c-d --reconfig" then > > hand edit the results manually thereafter myself. > > > > If it's not in bugzilla already, it's probably worth reporting though. > > It's in there twice: > > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176289 > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=172036 > > -Paul > __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ?gratis! Reg?strate ya - http://correo.yahoo.com.mx/ From felipe.alfaro at gmail.com Sun Dec 25 01:40:53 2005 From: felipe.alfaro at gmail.com (Felipe Alfaro Solana) Date: Sun, 25 Dec 2005 02:40:53 +0100 Subject: VMWare tools on Fedora Core 5 In-Reply-To: <1135474050.3119.35.camel@athlon2000> References: <1135372875.15202.17.camel@localhost.localdomain> <20051223214947.63713.qmail@web60718.mail.yahoo.com> <1135431660.5814.8.camel@localhost.localdomain> <1135433486.1969.22.camel@ignacio.lan> <1135474050.3119.35.camel@athlon2000> Message-ID: <6f6293f10512241740h5b24a1c3ye47c357798920202@mail.gmail.com> > But I'm a little confused, some of you have been talking about that a CD > is necessary to configure the VMWare tools. I just downloaded and > installed the RPM from the VMWare web site, in my case there is no > CD. The "CD" is not a real CD, but a virtual CD emulated by VMware that gets activated when you chose "Install VMWare Tools" from the VMWare menu. Once activated, you can mount the CD from inside your guest OS as usual. From kevinverma at gmail.com Sun Dec 25 11:22:18 2005 From: kevinverma at gmail.com (Kevin Verma) Date: Sun, 25 Dec 2005 16:52:18 +0530 Subject: ssh to a FC5 test1 system fails, fails to create pts device nodes with 2.6.14-1.1783 Message-ID: Hello, I updated the kernel to kernel-2.6.14-1.1783_FC5 on a FC5 test1 machine, and after reboot I could not log on to it via ssh, the error message in log files were as following: (hand typed) tailf -f /var/log/secure sshd (pid): Accepted public key for root from 192.168.0.3 sshd (pid): pam_unix(sshd:session): session opened for user root by (uid=0) sshd (pid): error: openpty: no such file or directory sshd (pid): session_pty_req: session 0 alloc failed Looking into /dev/pts/ , there are zero files. I'll like to know if this report has got attention of the kernel package developers and to suggest an intermediate fix. Cheers, From arjan at fenrus.demon.nl Sun Dec 25 11:33:44 2005 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Sun, 25 Dec 2005 12:33:44 +0100 Subject: ssh to a FC5 test1 system fails, fails to create pts device nodes with 2.6.14-1.1783 In-Reply-To: References: Message-ID: <1135510425.2946.14.camel@laptopd505.fenrus.org> On Sun, 2005-12-25 at 16:52 +0530, Kevin Verma wrote: > Hello, > > I updated the kernel to kernel-2.6.14-1.1783_FC5 on a FC5 test1 > machine, and after reboot I could not log on to it via ssh, the error > message in log files were as following: > (hand typed) > > tailf -f /var/log/secure > sshd (pid): Accepted public key for root from 192.168.0.3 > sshd (pid): pam_unix(sshd:session): session opened for user root by (uid=0) > sshd (pid): error: openpty: no such file or directory > sshd (pid): session_pty_req: session 0 alloc failed > > Looking into /dev/pts/ , there are zero files. this most likely is an initscripts issue; /dev/pts needs to be mounted.. and from the sound of what you have... it's not. From kevinverma at gmail.com Sun Dec 25 12:15:26 2005 From: kevinverma at gmail.com (Kevin Verma) Date: Sun, 25 Dec 2005 17:45:26 +0530 Subject: ssh to a FC5 test1 system fails, fails to create pts device nodes with 2.6.14-1.1783 In-Reply-To: <1135510425.2946.14.camel@laptopd505.fenrus.org> References: <1135510425.2946.14.camel@laptopd505.fenrus.org> Message-ID: Hello Arjan, You are right it is same situation with the older kernel as I just rebooted to that. However /dev/pts is mounted already /dev/devpts on /dev/pts type devpts (rw,gid=5,mode=620) Done the update of initscripts but same problem, I'll update my investigation here soon. Cheers, On 12/25/05, Arjan van de Ven wrote: > On Sun, 2005-12-25 at 16:52 +0530, Kevin Verma wrote: > > Hello, > > > > I updated the kernel to kernel-2.6.14-1.1783_FC5 on a FC5 test1 > > machine, and after reboot I could not log on to it via ssh, the error > > message in log files were as following: > > (hand typed) > > > > tailf -f /var/log/secure > > sshd (pid): Accepted public key for root from 192.168.0.3 > > sshd (pid): pam_unix(sshd:session): session opened for user root by (uid=0) > > sshd (pid): error: openpty: no such file or directory > > sshd (pid): session_pty_req: session 0 alloc failed > > > > Looking into /dev/pts/ , there are zero files. > > this most likely is an initscripts issue; /dev/pts needs to be mounted.. > and from the sound of what you have... it's not. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From sundaram at redhat.com Sun Dec 25 12:37:55 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Sun, 25 Dec 2005 18:07:55 +0530 Subject: ssh to a FC5 test1 system fails, fails to create pts device nodes with 2.6.14-1.1783 In-Reply-To: References: <1135510425.2946.14.camel@laptopd505.fenrus.org> Message-ID: <43AE92A3.1020901@redhat.com> Kevin Verma wrote: >Hello Arjan, > >You are right it is same situation with the older kernel as I just >rebooted to that. However /dev/pts is mounted already > >/dev/devpts on /dev/pts type devpts (rw,gid=5,mode=620) > >Done the update of initscripts but same problem, I'll update my >investigation here soon. > and remember to file a bug report post investigation. -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From kevinverma at gmail.com Sun Dec 25 14:43:32 2005 From: kevinverma at gmail.com (Kevin Verma) Date: Sun, 25 Dec 2005 20:13:32 +0530 Subject: ssh to a FC5 test1 system fails, fails to create pts device nodes with 2.6.14-1.1783 In-Reply-To: <43AE92A3.1020901@redhat.com> References: <1135510425.2946.14.camel@laptopd505.fenrus.org> <43AE92A3.1020901@redhat.com> Message-ID: Sure will file bug reports when done, meanwhile some of the logs messeges I am pasting here: Dec 25 11:48:35 server1 udevinfo[1874]: udev_db_get_all_entries: unable to open udev_db '/dev/.udev/db': No such file or dir ectory Oh is that the problem caused by recent udev update "udev-078-2" ; Yes and got fixed when I removed the udev update and made a fall back to original "udev-075-4" So the system booted fine and I could log in via ssh and no error messages that caught my extreme focus exept "kudzu" which had a segfault while kudzu startup. Thanks to all please continue this thread if you find anything related. Cheers, On 12/25/05, Rahul Sundaram wrote: > Kevin Verma wrote: > > >Hello Arjan, > > > >You are right it is same situation with the older kernel as I just > >rebooted to that. However /dev/pts is mounted already > > > >/dev/devpts on /dev/pts type devpts (rw,gid=5,mode=620) > > > >Done the update of initscripts but same problem, I'll update my > >investigation here soon. > > > and remember to file a bug report post investigation. > > -- > Rahul > > Learn. Network. Experience open source. > Red Hat Summit Nashville | May 30 - June 2, 2006 > Learn more: http://www.redhat.com/promo/summit/ > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list > From stickster at gmail.com Sun Dec 25 16:29:16 2005 From: stickster at gmail.com (Paul W. Frields) Date: Sun, 25 Dec 2005 11:29:16 -0500 Subject: Palm sync status? In-Reply-To: <20051224165546.7fab755f.zaitcev@redhat.com> References: <1135413325.3721.2.camel@rivendell.home.local> <1135432018.5814.14.camel@localhost.localdomain> <20051224165546.7fab755f.zaitcev@redhat.com> Message-ID: <1135528156.10931.10.camel@localhost.localdomain> On Sat, 2005-12-24 at 16:55 -0800, Pete Zaitcev wrote: > On Sat, 24 Dec 2005 08:46:58 -0500, "Paul W. Frields" wrote: > > > > My Handspring Visor Platinum works with JPilot on FC4 provided that I > > > manually create the /dev/ttyUSB* files before each synchronization. > > > I fixed this problem some time ago, IIRC, by simply adding a file > > "/etc/udev/rules.d/95-visor.rules" that has just this line: > > > > KERNEL="ttyUSB1",SYMLINK="pilot" > > This seems to be a different problem, unless the other guy is not > seriously mistaken. In his case the original device nodes were not > created. Whoops, I didn't read carefully enough. I guess the OP might be able to rememdy through editing /etc/hotplug/ stuff, if the attachment's being picked up (q.v. lsusb), right? > > In the future, shouldn't these issues go to fedora-list and not > > fedora-devel-list? > > If we were talking about a proposed patch for udev, it would belong > here. I keep the hope. > > There would also be a significant development content if we dicussed > how to find a Pilot in a more robust way with udev. The thing is, > we cannot ship KERNEL="ttyUSB1", because of dynamic numbering. Not to mention that it's not entirely clear which PalmOS devices use the even device numbers as opposed to odd -- e.g. ttyUSB0 or ttyUSB1. I'm sure this information can be discovered, but I've not looked for a list either. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- 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 stickster at gmail.com Sun Dec 25 16:34:04 2005 From: stickster at gmail.com (Paul W. Frields) Date: Sun, 25 Dec 2005 11:34:04 -0500 Subject: VMWare tools on Fedora Core 5 In-Reply-To: <6f6293f10512241740h5b24a1c3ye47c357798920202@mail.gmail.com> References: <1135372875.15202.17.camel@localhost.localdomain> <20051223214947.63713.qmail@web60718.mail.yahoo.com> <1135431660.5814.8.camel@localhost.localdomain> <1135433486.1969.22.camel@ignacio.lan> <1135474050.3119.35.camel@athlon2000> <6f6293f10512241740h5b24a1c3ye47c357798920202@mail.gmail.com> Message-ID: <1135528444.10931.14.camel@localhost.localdomain> On Sun, 2005-12-25 at 02:40 +0100, Felipe Alfaro Solana wrote: > > But I'm a little confused, some of you have been talking about that a CD > > is necessary to configure the VMWare tools. I just downloaded and > > installed the RPM from the VMWare web site, in my case there is no > > CD. > > The "CD" is not a real CD, but a virtual CD emulated by VMware that > gets activated when you chose "Install VMWare Tools" from the VMWare > menu. Once activated, you can mount the CD from inside your guest OS > as usual. Right, and then, after you install the RPM inside the guest OS (using "rpm -ivh" as root), you will find you have a vmware-config-tools.pl script available... again, make sure you have gcc and kernel-devel installed. Then run as root and enjoy. -- Paul W. Frields, RHCE http://paul.frields.org/ gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233 5906 ACDB C937 BD11 3717 Fedora Documentation Project: http://fedora.redhat.com/projects/docs/ -------------- 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 m.f.h at web.de Sun Dec 25 18:54:57 2005 From: m.f.h at web.de (Marcus Hartig) Date: Sun, 25 Dec 2005 19:54:57 +0100 Subject: Merry Christmas! Message-ID: <43AEEB01.9090104@web.de> Merry Christmas to all Fedora developers and users! Enjoy the time with the family! Best wishes and regards, Marcus From seandarcy2 at gmail.com Sun Dec 25 22:49:38 2005 From: seandarcy2 at gmail.com (sean darcy) Date: Sun, 25 Dec 2005 14:49:38 -0800 Subject: udev makes /dev/raw1394, but no module In-Reply-To: <20051224165813.009ef0b0.zaitcev@redhat.com> References: <20051224165813.009ef0b0.zaitcev@redhat.com> Message-ID: Pete Zaitcev wrote: > On Sat, 24 Dec 2005 16:36:48 -0800, sean darcy wrote: > > >>udev should be loading the modules, correct? But why is it creating the >>/dev entries if it's not loading the modules? Is this a feature, or a >>bug? Does udev only create the dev entries, and the user is supposed to >>load the modules? > > > Most likely the modules fail the initialization and return from their > probe() with an error. > Maybe, but modprobe raw1394 works, and does not return any error. In fact, the way I've hacked this is just to modprobe the 1394 modules in rc.local, which works just fine. sean From d.jacobfeuerborn at conversis.de Sun Dec 25 22:50:33 2005 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Sun, 25 Dec 2005 23:50:33 +0100 Subject: Debugging kernel hangs Message-ID: <43AF2239.9070201@conversis.de> Hi, what is the proper way to analyze kernel hangs? I'm getting hit by this almost on a daily basis ever since moving to the 177x kernels and now I'm trying to get down to what the actual problem is. I only have one machine available so a method to get debugging information as a dump in a core file would be preferred but I could get a second machine attached to get that information via the serial console if necessary, I just can't keep the second machine around all the time. Regards, Dennis From walovaton at yahoo.com.mx Sun Dec 25 22:51:14 2005 From: walovaton at yahoo.com.mx (William Lovaton) Date: Sun, 25 Dec 2005 17:51:14 -0500 Subject: VMWare tools on Fedora Core 5 In-Reply-To: <1135528444.10931.14.camel@localhost.localdomain> References: <1135372875.15202.17.camel@localhost.localdomain> <20051223214947.63713.qmail@web60718.mail.yahoo.com> <1135431660.5814.8.camel@localhost.localdomain> <1135433486.1969.22.camel@ignacio.lan> <1135474050.3119.35.camel@athlon2000> <6f6293f10512241740h5b24a1c3ye47c357798920202@mail.gmail.com> <1135528444.10931.14.camel@localhost.localdomain> Message-ID: <1135551074.2527.5.camel@athlon2000> Wooowww! that's very clever, I'll try that as soon as I get to my office. Thanks a lot to all of you guys!. -William El dom, 25-12-2005 a las 11:34 -0500, Paul W. Frields escribi??: > On Sun, 2005-12-25 at 02:40 +0100, Felipe Alfaro Solana wrote: > > > But I'm a little confused, some of you have been talking about that a CD > > > is necessary to configure the VMWare tools. I just downloaded and > > > installed the RPM from the VMWare web site, in my case there is no > > > CD. > > > > The "CD" is not a real CD, but a virtual CD emulated by VMware that > > gets activated when you chose "Install VMWare Tools" from the VMWare > > menu. Once activated, you can mount the CD from inside your guest OS > > as usual. > > Right, and then, after you install the RPM inside the guest OS (using > "rpm -ivh" as root), you will find you have a vmware-config-tools.pl > script available... again, make sure you have gcc and kernel-devel > installed. Then run as root and enjoy. > > -- > fedora-devel-list mailing list > fedora-devel-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-devel-list __________________________________________________ Correo Yahoo! Espacio para todos tus mensajes, antivirus y antispam ?gratis! Reg?strate ya - http://correo.yahoo.com.mx/ From ianburrell at gmail.com Mon Dec 26 03:40:01 2005 From: ianburrell at gmail.com (Ian Burrell) Date: Sun, 25 Dec 2005 19:40:01 -0800 Subject: Palm sync status? In-Reply-To: References: Message-ID: On 12/23/05, David L wrote: > > I just bought a Treo 650 and was looking for info about how to use it with > FC4 when I found a posting which says FC4 is "completely broken with respect > to Palm syncronization". Is this supposed to be addressed in FC5, or should > I "downgrade" to FC3? Has anybody synced a Treo with Evolution in > FC5-test1? I asked this message on fedora-list and somebody responded > saying that there was a discussion on this list. But I haven't been able to > find anything definitive that says whether FC5 is supposed to fix the FC4 > syncing problems. Does anyone know? Will I be able to sync a Treo 650 with > evolution? > The updates to pilot-link in FC4 fixed the synchronization issues for me. The pilot-link is rawhide has been working. The remaining issue in FC4 for me is that it takes a long time for the /dev/ttyUSB1 device node to be created. I use a static device node as a work around. The udev in rawhide creates the device nodes much faster. This solves the final issue in using the pilot-link utilities. I don't know about the GUI programs which use pilot-link library, like evolution, jpilot, and gnome-pilot. The pilot-link API changed with the 0.12-pre versions which means the programs need to be updated for the new API and don't know if that has been done yet. - Ian From kevinverma at gmail.com Mon Dec 26 07:36:14 2005 From: kevinverma at gmail.com (Kevin Verma) Date: Mon, 26 Dec 2005 13:06:14 +0530 Subject: testing PCMCIA setup under FC5, for Sierra Aircard555 CMDA modem Message-ID: Hello, I am very excited about the newer PCMCIA implementation in accord with hotplug. I was trying to setup my Sierra Wireless Aircard 555 under FC5 test1 and hit the obvious bumps. Below is a URL where I have documented some of my understanding for the newer systems as it works: my_blog_url_ Below a URL where Rahul S. has added to the Fedora Release notes overview: rahul_fc_wiki_url_ After patching (as on blog_url above) the serial_cs.c, I noticed that this PCMCIA device reports different manufacture_id on FC4 and FC5, further I noticed the same is happening on FC5 box before and after manual firmware loading as below in command line snippet. Before you look into the snippet below I will also like to point out that confused about different manufacture_id reporting I re-patched the serial_cs.c and below is what is being used for the snippet bellow, here: +PCMCIA_DEVICE_CIS_MANF_CARD(0x013f, 0xa555, "SW_555_SER.cis"), /* Sierra Aircard 555 CDMA 1xrtt Modem */ ---snip from FC5 test1 start--- [root at server1 ~]# pccardctl eject [root at server1 ~]# pccardctl insert [root at server1 ~]# pccardctl info PRODID_1="Sierra Wireless" PRODID_2="AirCard 555" PRODID_3="A555" PRODID_4="Rev 1" MANFID=0192,a555 FUNCID=6 [root at server1 ~]# wvdialconf foo.conf Scanning your serial ports for a modem. ttyS0<*1>: ATQ0 V1 E1 -- failed with 2400 baud, next try: 9600 baud ttyS0<*1>: ATQ0 V1 E1 -- failed with 9600 baud, next try: 115200 baud ttyS0<*1>: ATQ0 V1 E1 -- and failed too at 115200, giving up. Port Scan<*1>: S1 S2 S3 S4 S5 S6 S7 S8 Port Scan<*1>: S9 S10 S11 S12 S13 S14 S15 S16 Port Scan<*1>: S17 S18 S19 S20 S21 S22 S23 S24 Port Scan<*1>: S25 S26 S27 S28 S29 S30 S31 Sorry, no modem was detected! Is it in use by another program? Did you configure it properly with setserial? Please read the FAQ at http://open.nit.ca/wvdial/ If you still have problems, send mail to wvdial-list at lists.nit.ca. [root at server1 ~]# pcmcia-socket-startup [root at server1 ~]# wvdialconf foo.conf Scanning your serial ports for a modem. ttyS0<*1>: ATQ0 V1 E1 -- failed with 2400 baud, next try: 9600 baud ttyS0<*1>: ATQ0 V1 E1 -- failed with 9600 baud, next try: 115200 baud ttyS0<*1>: ATQ0 V1 E1 -- and failed too at 115200, giving up. Port Scan<*1>: S1 S2 S3 S4 S5 S6 S7 S8 Port Scan<*1>: S9 S10 S11 S12 S13 S14 S15 S16 Port Scan<*1>: S17 S18 S19 S20 S21 S22 S23 S24 Port Scan<*1>: S25 S26 S27 S28 S29 S30 S31 Sorry, no modem was detected! Is it in use by another program? Did you configure it properly with setserial? Please read the FAQ at http://open.nit.ca/wvdial/ If you still have problems, send mail to wvdial-list at lists.nit.ca. [root at server1 ~]# cat /lib/firmware/SW_555_SER.cis > /sys/class/pcmcia_socket/pcmcia_socket0/cis [root at server1 ~]# pcmcia-socket-startup [root at server1 ~]# wvdialconf foo.conf Scanning your serial ports for a modem. ttyS0<*1>: ATQ0 V1 E1 -- failed with 2400 baud, next try: 9600 baud ttyS0<*1>: ATQ0 V1 E1 -- failed with 9600 baud, next try: 115200 baud ttyS0<*1>: ATQ0 V1 E1 -- and failed too at 115200, giving up. ttyS1<*1>: ATQ0 V1 E1 -- failed with 2400 baud, next try: 9600 baud ttyS1<*1>: ATQ0 V1 E1 -- failed with 9600 baud, next try: 115200 baud ttyS1<*1>: ATQ0 V1 E1 -- OK ttyS1<*1>: ATQ0 V1 E1 Z -- OK ttyS1<*1>: ATQ0 V1 E1 S0=0 -- OK ttyS1<*1>: ATQ0 V1 E1 S0=0 &C1 -- OK ttyS1<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 -- OK ttyS1<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- OK ttyS1<*1>: Modem Identifier: ATI -- ERROR ttyS1<*1>: Max speed is 115200; that should be safe. ttyS1<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- OK Port Scan<*1>: S3 S4 S5 S6 S7 S8 S9 S10 Port Scan<*1>: S11 S12 S13 S14 S15 S16 S17 S18 Port Scan<*1>: S19 S20 S21 S22 S23 S24 S25 S26 Port Scan<*1>: S27 S28 S29 S30 S31 Found a modem on /dev/ttyS1. Modem configuration written to foo.conf. ttyS1: Speed 115200; init "ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0" [root at server1 ~]# less wvdial.conf [root at server1 ~]# vim wvdial.conf [root at server1 ~]# pccardctl info PRODID_1="Sierra Wireless" PRODID_2="AirCard 555" PRODID_3="A555" PRODID_4="Rev 1" MANFID=013f,0710 FUNCID=2 [root at server1 ~]# ---snip FC5 test1 end--- the virsions if you want to know are: 2.6.14-prep (kernel-2.6.14-1.1783_FC5 - src) pcmciautils-011-1 hotplug-2004_09_23-10 So finally this modem seems ready on expected ttyS1 and ready for connection to be established, I'll also liek to have any suggestions how this can be more fine tuned automatic further, and some help for understating the manufacture_id issue. Thanks, From kevinverma at gmail.com Mon Dec 26 07:38:27 2005 From: kevinverma at gmail.com (Kevin Verma) Date: Mon, 26 Dec 2005 13:08:27 +0530 Subject: testing PCMCIA setup under FC5, for Sierra Aircard555 CMDA modem (url's updated) Message-ID: Hello, I am very excited about the newer PCMCIA implementation in accord with hotplug. I was trying to setup my Sierra Wireless Aircard 555 under FC5 test1 and hit the obvious bumps. Below is a URL where I have documented some of my understanding for the newer systems as it works: http://www.bloglines.com/blog/kevinverma?id=39 Below a URL where Rahul S. has added to the Fedora Release notes overview: http://fedoraproject.org/wiki/Docs/Beats/OverView After patching (as on blog_url above) the serial_cs.c, I noticed that this PCMCIA device reports different manufacture_id on FC4 and FC5, further I noticed the same is happening on FC5 box before and after manual firmware loading as below in command line snippet. Before you look into the snippet below I will also like to point out that confused about different manufacture_id reporting I re-patched the serial_cs.c and below is what is being used for the snippet bellow, here: +PCMCIA_DEVICE_CIS_MANF_CARD(0x013f, 0xa555, "SW_555_SER.cis"), /* Sierra Aircard 555 CDMA 1xrtt Modem */ ---snip from FC5 test1 start--- [root at server1 ~]# pccardctl eject [root at server1 ~]# pccardctl insert [root at server1 ~]# pccardctl info PRODID_1="Sierra Wireless" PRODID_2="AirCard 555" PRODID_3="A555" PRODID_4="Rev 1" MANFID=0192,a555 FUNCID=6 [root at server1 ~]# wvdialconf foo.conf Scanning your serial ports for a modem. ttyS0<*1>: ATQ0 V1 E1 -- failed with 2400 baud, next try: 9600 baud ttyS0<*1>: ATQ0 V1 E1 -- failed with 9600 baud, next try: 115200 baud ttyS0<*1>: ATQ0 V1 E1 -- and failed too at 115200, giving up. Port Scan<*1>: S1 S2 S3 S4 S5 S6 S7 S8 Port Scan<*1>: S9 S10 S11 S12 S13 S14 S15 S16 Port Scan<*1>: S17 S18 S19 S20 S21 S22 S23 S24 Port Scan<*1>: S25 S26 S27 S28 S29 S30 S31 Sorry, no modem was detected! Is it in use by another program? Did you configure it properly with setserial? Please read the FAQ at http://open.nit.ca/wvdial/ If you still have problems, send mail to wvdial-list at lists.nit.ca. [root at server1 ~]# pcmcia-socket-startup [root at server1 ~]# wvdialconf foo.conf Scanning your serial ports for a modem. ttyS0<*1>: ATQ0 V1 E1 -- failed with 2400 baud, next try: 9600 baud ttyS0<*1>: ATQ0 V1 E1 -- failed with 9600 baud, next try: 115200 baud ttyS0<*1>: ATQ0 V1 E1 -- and failed too at 115200, giving up. Port Scan<*1>: S1 S2 S3 S4 S5 S6 S7 S8 Port Scan<*1>: S9 S10 S11 S12 S13 S14 S15 S16 Port Scan<*1>: S17 S18 S19 S20 S21 S22 S23 S24 Port Scan<*1>: S25 S26 S27 S28 S29 S30 S31 Sorry, no modem was detected! Is it in use by another program? Did you configure it properly with setserial? Please read the FAQ at http://open.nit.ca/wvdial/ If you still have problems, send mail to wvdial-list at lists.nit.ca. [root at server1 ~]# cat /lib/firmware/SW_555_SER.cis > /sys/class/pcmcia_socket/pcmcia_socket0/cis [root at server1 ~]# pcmcia-socket-startup [root at server1 ~]# wvdialconf foo.conf Scanning your serial ports for a modem. ttyS0<*1>: ATQ0 V1 E1 -- failed with 2400 baud, next try: 9600 baud ttyS0<*1>: ATQ0 V1 E1 -- failed with 9600 baud, next try: 115200 baud ttyS0<*1>: ATQ0 V1 E1 -- and failed too at 115200, giving up. ttyS1<*1>: ATQ0 V1 E1 -- failed with 2400 baud, next try: 9600 baud ttyS1<*1>: ATQ0 V1 E1 -- failed with 9600 baud, next try: 115200 baud ttyS1<*1>: ATQ0 V1 E1 -- OK ttyS1<*1>: ATQ0 V1 E1 Z -- OK ttyS1<*1>: ATQ0 V1 E1 S0=0 -- OK ttyS1<*1>: ATQ0 V1 E1 S0=0 &C1 -- OK ttyS1<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 -- OK ttyS1<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- OK ttyS1<*1>: Modem Identifier: ATI -- ERROR ttyS1<*1>: Max speed is 115200; that should be safe. ttyS1<*1>: ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0 -- OK Port Scan<*1>: S3 S4 S5 S6 S7 S8 S9 S10 Port Scan<*1>: S11 S12 S13 S14 S15 S16 S17 S18 Port Scan<*1>: S19 S20 S21 S22 S23 S24 S25 S26 Port Scan<*1>: S27 S28 S29 S30 S31 Found a modem on /dev/ttyS1. Modem configuration written to foo.conf. ttyS1: Speed 115200; init "ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0" [root at server1 ~]# less wvdial.conf [root at server1 ~]# vim wvdial.conf [root at server1 ~]# pccardctl info PRODID_1="Sierra Wireless" PRODID_2="AirCard 555" PRODID_3="A555" PRODID_4="Rev 1" MANFID=013f,0710 FUNCID=2 [root at server1 ~]# ---snip FC5 test1 end--- the virsions if you want to know are: 2.6.14-prep (kernel-2.6.14-1.1783_FC5 - src) pcmciautils-011-1 hotplug-2004_09_23-10 So finally this modem seems ready on expected ttyS1 and ready for connection to be established, I'll also liek to have any suggestions how this can be more fine tuned automatic further, and some help for understating the manufacture_id issue. Thanks, From gilboad at gmail.com Mon Dec 26 07:48:38 2005 From: gilboad at gmail.com (Gilboa Davara) Date: Mon, 26 Dec 2005 09:48:38 +0200 Subject: mock how-to? Message-ID: <1135583318.19522.2.camel@gilboa-work-dev> Hello all, Can anybody point me to a good mock (Fedora's build environment) HOW-TO? The main mock site (http://fedoraproject.org/wiki/Projects/Mock) is a bit lacking... Gilboa From admin at ramshacklestudios.com Mon Dec 26 07:53:47 2005 From: admin at ramshacklestudios.com (Peter Gordon) Date: Sun, 25 Dec 2005 23:53:47 -0800 Subject: mock how-to? In-Reply-To: <1135583318.19522.2.camel@gilboa-work-dev> References: <1135583318.19522.2.camel@gilboa-work-dev> Message-ID: <1135583627.4830.0.camel@tuxhugger> On Mon, 2005-12-26 at 09:48 +0200, Gilboa Davara wrote: > Hello all, > > Can anybody point me to a good mock (Fedora's build environment) HOW-TO? > The main mock site (http://fedoraproject.org/wiki/Projects/Mock) is a > bit lacking... The Wiki has a draft[1] that might help. :-/ [1] http://fedoraproject.org/wiki/Docs/Drafts/BuildingPackagesGuide -- Peter Gordon (codergeek42) GnuPG Public Key: 0xDA3634D7 -------------- 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 Mon Dec 26 08:09:30 2005 From: gilboad at gmail.com (Gilboa Davara) Date: Mon, 26 Dec 2005 10:09:30 +0200 Subject: mock how-to? In-Reply-To: <1135583627.4830.0.camel@tuxhugger> References: <1135583318.19522.2.camel@gilboa-work-dev> <1135583627.4830.0.camel@tuxhugger> Message-ID: <1135584570.19522.8.camel@gilboa-work-dev> On Sun, 2005-12-25 at 23:53 -0800, Peter Gordon wrote: > On Mon, 2005-12-26 at 09:48 +0200, Gilboa Davara wrote: > > Hello all, > > > > Can anybody point me to a good mock (Fedora's build environment) HOW-TO? > > The main mock site (http://fedoraproject.org/wiki/Projects/Mock) is a > > bit lacking... > > The Wiki has a draft[1] that might help. :-/ > > [1] http://fedoraproject.org/wiki/Docs/Drafts/BuildingPackagesGuide Thanks. But is there any "how to use Mock in a multi-platform environment HOW-TO"? (I need to build RPMs for both FC4/64 and RHL4/64) Thanks, Gilboa From buildsys at redhat.com Mon Dec 26 08:12:56 2005 From: buildsys at redhat.com (Build System) Date: Mon, 26 Dec 2005 03:12:56 -0500 Subject: rawhide report: 20051226 changes Message-ID: <200512260812.jBQ8Cu3m007769@porkchop.devel.redhat.com> New package elilo ELILO linux boot loader for EFI-based systems New package gnu-efi Development Libraries and headers for EFI New package libpfm a performance monitoring library for Linux/ia64 New package libunwind An unwinding library for ia64. New package pfmon a performance monitoring tool for Linux/ia64 New package prctl Utility to perform process operations New package salinfo SAL info tool. Updated Packages: dmidecode-1:2.6-1.14 -------------------- * Fri Apr 15 2005 Florian La Roche - remove empty scripts * Wed Mar 02 2005 Dave Jones - Update to upstream 2.6 * Tue Mar 01 2005 Dave Jones - Rebuild for gcc4 kernel-2.6.14-1.1786_FC5 ------------------------ * Sun Dec 25 2005 Dave Jones - 2.6.15-rc7 - bah humbug. rgmanager-1.9.31-3 ------------------ * Thu May 05 2005 Chris Feist - Cleaned up .spec file. * Thu May 05 2005 Chris Feist - Added patch to disable starting up the init scripts. * Mon Dec 20 2004 Chris Feist - Rebuild with new sources. Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.2.i686 requires /lib/modules/2.6.14-1.1775_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.2.i686 requires kernel = 0:2.6.14-1.1775_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.2.i686 requires kernel-smp = 0:2.6.14-1.1775_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.2.i686 requires /lib/modules/2.6.14-1.1775_FC5smp cman-kernel - 2.6.14.1-20051219.162641.FC5.3.i686 requires /lib/modules/2.6.14-1.1775_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.3.i686 requires kernel = 0:2.6.14-1.1775_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.3.i686 requires kernel-smp = 0:2.6.14-1.1775_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.3.i686 requires /lib/modules/2.6.14-1.1775_FC5smp dlm-kernel - 2.6.14.1-20051219.162641.FC5.3.i686 requires /lib/modules/2.6.14-1.1783_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.3.i686 requires kernel = 0:2.6.14-1.1783_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.3.i686 requires /lib/modules/2.6.14-1.1783_FC5smp dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.3.i686 requires kernel-smp = 0:2.6.14-1.1783_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.4.i686 requires /lib/modules/2.6.14-1.1777_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.4.i686 requires kernel = 0:2.6.14-1.1777_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.4.i686 requires /lib/modules/2.6.14-1.1777_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.4.i686 requires kernel-smp = 0:2.6.14-1.1777_FC5 jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 Broken deps for ia64 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) Broken deps for s390 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 Broken deps for s390x ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.2.x86_64 requires /lib/modules/2.6.14-1.1775_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.2.x86_64 requires kernel = 0:2.6.14-1.1775_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.3.x86_64 requires /lib/modules/2.6.14-1.1775_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.3.x86_64 requires kernel = 0:2.6.14-1.1775_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.3.x86_64 requires /lib/modules/2.6.14-1.1783_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.3.x86_64 requires kernel = 0:2.6.14-1.1783_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.4.x86_64 requires /lib/modules/2.6.14-1.1777_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.4.x86_64 requires kernel = 0:2.6.14-1.1777_FC5 jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) From thomas at apestaart.org Mon Dec 26 09:38:43 2005 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Mon, 26 Dec 2005 10:38:43 +0100 Subject: Royalty free gstreamer plug-in In-Reply-To: <37989.81.64.157.3.1135370193.squirrel@rousalka.dyndns.org> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <1135352741.15650.54.camel@thomas.amantes> <43AC2336.3030909@n-man.com> <604aa7910512230826u4c22d27ftdfb051dd1605da18@mail.gmail.com> <43AC2674.6060601@n-man.com> <604aa7910512230857j12d52d0eo52e25a0877b4a4da@mail.gmail.com> <43AC2FA5.1030601@laposte.net> <1135361609.15650.83.camel@thomas.amantes> <37989.81.64.157.3.1135370193.squirrel@rousalka.dyndns.org> Message-ID: <1135589923.3153.69.camel@thomas.amantes> Hi, > On Ven 23 d?cembre 2005 19:13, Thomas Vander Stichele wrote: > > > Also, when was the last time that in a traditional closed software offer > > you could see the source, make changes to it, submit the changes, and > > get legal use out of your changes by using the next version of the > > binary that gets released ? > > > > You're trying to paint it a lot more black and white than it is, I > > think. > > This is a lot less exceptional than you think. Microsoft shared source > program is pretty much the same thing. Heh, you're showing your innate negativity too easily by comparing it to this. I'm pretty sure I can't look at Microsoft code for Windows *right now*, and even if I could, I'm pretty sure I can't expect a fix I send to be available any time soon. > Here only upstream is allowed to release legit binaries, so you don't get > the vendor freedom real FOSS permits. You conveniently omitted the fact that I've mentioned before - *everyone* downstream is free to sign this distribution contract with us. > The point of pure FOSS distros like FC is they're not benevolent > dictatorships. You don't like them you can leave them taking with you 100% > of the code and associated rebuild rights. > > As you admitted yourself a Centos-like effort would have to drop the mp3 > plugin. Again, you conveniently dropped half of what I said. I also said Centos could easily sign this contract with us and redistribute the mp3 plugin. I am getting the feeling you are dropping facts on purpose. I expected better. > So it's definitely not free (I'll grant you the open part) We never claimed it was "Free Software". Of course it's not 100% Free Software in the sense that GNU would want it. The reason is pretty simple - within the constraints of the patent issue it is not possible to deliver a completely Free Software solution. Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> - Nice wheels. - Came with the car. <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From thomas at apestaart.org Mon Dec 26 09:48:28 2005 From: thomas at apestaart.org (Thomas Vander Stichele) Date: Mon, 26 Dec 2005 10:48:28 +0100 Subject: Royalty free gstreamer plug-in In-Reply-To: <1135371783.7522.11.camel@locolhost.localdomain> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <604aa7910512230752p5f506333se69a4171abf6c811@mail.gmail.com> <43AC2534.2090903@n-man.com> <604aa7910512230830q22353473xa38f3e682dc01bfc@mail.gmail.com> <43AC3562.5000103@n-man.com> <1135371783.7522.11.camel@locolhost.localdomain> Message-ID: <1135590508.3153.76.camel@smtp.localdomain> Hi, > Rhythmbox uses gstreamer, it would be gstreamer that uses the plugin. > Rhythmbox does not link against the plugin, does not require the plugin, > etc. For that matter - neither does gstreamer. > > I don't think there would be a legal problem. > If there was - can I use my X11 server which is MIT to display an emacs > window? What about emacs opening an X11 window? You're talking about something that is MIT vs. something that is GPL or LGPL - I don't think your analogy would tell us anything. But even if X11 would be GPL or LGPL - interaction with the X server is done through the X protocol. Interpretation of the "linking to" language in GPL and LGPL varies, but most parties agree that it boils down to "does the code at runtime execute in the same execution space". In practice, this means "dynamic or static linking". So if X were GPL/LGPL, and you had a binary application talking to it, that would be fine as long as the libX11 used to implement the protocol is MIT or similar. > I don't see a difference between that and rhythmbox using gstreamer > (lgp) which talks to this plugin. There really is. If you are interested, read http://gstreamer.freedesktop.org/documentation/licensing.html Thomas Dave/Dina : future TV today ! - http://www.davedina.org/ <-*- thomas (dot) apestaart (dot) org -*-> Don't change your name keep it the same for fear I may lose you again I know you won't it's just that I am unorganized and I want to find you when Something good happens <-*- thomas (at) apestaart (dot) org -*-> URGent, best radio on the net - 24/7 ! - http://urgent.fm/ From Nicolas.Mailhot at laPoste.net Mon Dec 26 10:21:01 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Mon, 26 Dec 2005 11:21:01 +0100 Subject: Royalty free gstreamer plug-in In-Reply-To: <1135589923.3153.69.camel@thomas.amantes> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <1135352741.15650.54.camel@thomas.amantes> <43AC2336.3030909@n-man.com> <604aa7910512230826u4c22d27ftdfb051dd1605da18@mail.gmail.com> <43AC2674.6060601@n-man.com> <604aa7910512230857j12d52d0eo52e25a0877b4a4da@mail.gmail.com> <43AC2FA5.1030601@laposte.net> <1135361609.15650.83.camel@thomas.amantes> <37989.81.64.157.3.1135370193.squirrel@rousalka.dyndns.org> <1135589923.3153.69.camel@thomas.amantes> Message-ID: <43AFC40D.2040901@laPoste.net> Thomas Vander Stichele a ?crit : >>The point of pure FOSS distros like FC is they're not benevolent >>dictatorships. You don't like them you can leave them taking with you 100% >>of the code and associated rebuild rights. >> >>As you admitted yourself a Centos-like effort would have to drop the mp3 >>plugin. > > > Again, you conveniently dropped half of what I said. I also said Centos > could easily sign this contract with us and redistribute the mp3 plugin. > I am getting the feeling you are dropping facts on purpose. I expected > better. What I'm pointing is you have a central choke point and rebuild rights are not retransmitted as-is to downstream users, you can't even workaround them (like for firefox) by dropping a few trademarks. And I don't doubt you intend to be nice with your agreement, but hte fact there *is* an agreement in any form is a show stopper -- Nicolas Mailhot From jeff.pitman at gmail.com Mon Dec 26 10:36:07 2005 From: jeff.pitman at gmail.com (Jeff Pitman) Date: Mon, 26 Dec 2005 18:36:07 +0800 Subject: Royalty free gstreamer plug-in In-Reply-To: <43AC2FA5.1030601@laposte.net> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <1135352741.15650.54.camel@thomas.amantes> <43AC2336.3030909@n-man.com> <604aa7910512230826u4c22d27ftdfb051dd1605da18@mail.gmail.com> <43AC2674.6060601@n-man.com> <604aa7910512230857j12d52d0eo52e25a0877b4a4da@mail.gmail.com> <43AC2FA5.1030601@laposte.net> Message-ID: <6b9c17630512260236vbb9d5a1l1aeffabcb7022b65@mail.gmail.com> On 12/24/05, Nicolas Mailhot wrote: > This proposal OTOH is pretty much your take it or leave it traditional > closed software offer. I disagree. If it were a traditional closed-source software offer, then the thread would have terminated long ago. What we have here is an offer that allows Fedora to, at the very least, explicitly point users to a friendly way to get MP3 support. Do we monitor the fedora-user list and other fedora forums to ensure that no mention of livna and freshrpms are made? These might constitute as patent violations because the comments are hosted by Redhat and are vehicles for which users can circumvent the patent-less distro. (Optimally, FC should just take up the offer and include it in the distro. Wasn't Redhat offering indemnication against ghost-cases of patent claims during the SCO debacle? How about MP3? :D) -- -jeff From ivazquez at ivazquez.net Mon Dec 26 12:38:38 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Mon, 26 Dec 2005 07:38:38 -0500 Subject: mock how-to? In-Reply-To: <1135584570.19522.8.camel@gilboa-work-dev> References: <1135583318.19522.2.camel@gilboa-work-dev> <1135583627.4830.0.camel@tuxhugger> <1135584570.19522.8.camel@gilboa-work-dev> Message-ID: <1135600718.30721.3.camel@ignacio.lan> On Mon, 2005-12-26 at 10:09 +0200, Gilboa Davara wrote: > But is there any "how to use Mock in a multi-platform environment > HOW-TO"? Oddly enough, you use it *exactly* how you would in a single-platform environment. > (I need to build RPMs for both FC4/64 and RHL4/64) Feel free to download and change this as required: http://www.karan.org/mock/EL4/i386/ -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 d.jacobfeuerborn at conversis.de Mon Dec 26 17:48:12 2005 From: d.jacobfeuerborn at conversis.de (Dennis Jacobfeuerborn) Date: Mon, 26 Dec 2005 18:48:12 +0100 Subject: Debugging kernel hangs In-Reply-To: <43AF2239.9070201@conversis.de> References: <43AF2239.9070201@conversis.de> Message-ID: <43B02CDC.8050500@conversis.de> Dennis Jacobfeuerborn wrote: > Hi, > what is the proper way to analyze kernel hangs? I'm getting hit by this > almost on a daily basis ever since moving to the 177x kernels and now > I'm trying to get down to what the actual problem is. I only have one > machine available so a method to get debugging information as a dump in > a core file would be preferred but I could get a second machine attached > to get that information via the serial console if necessary, I just > can't keep the second machine around all the time. After borrowing a notebook for a day I filed a bug and attached the netdump output here: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=176569 Regards, Dennis From davej at redhat.com Mon Dec 26 19:32:19 2005 From: davej at redhat.com (Dave Jones) Date: Mon, 26 Dec 2005 14:32:19 -0500 Subject: rawhide report: 20051226 changes In-Reply-To: <200512260812.jBQ8Cu3m007769@porkchop.devel.redhat.com> References: <200512260812.jBQ8Cu3m007769@porkchop.devel.redhat.com> Message-ID: <20051226193219.GA6070@redhat.com> On Mon, Dec 26, 2005 at 03:12:56AM -0500, Build System wrote: > New package salinfo > SAL info tool. Odd. This has been around for ages, (though I'm not entirely sure why, as it's ia64 only, and of limited use). > Updated Packages: > dmidecode-1:2.6-1.14 > -------------------- > * Fri Apr 15 2005 Florian La Roche > - remove empty scripts > > * Wed Mar 02 2005 Dave Jones > - Update to upstream 2.6 > > * Tue Mar 01 2005 Dave Jones > - Rebuild for gcc4 rawhide also has dmidecode-2.7-1.22 Why on earth did this ancient version pop up? Dave From katzj at redhat.com Mon Dec 26 19:42:18 2005 From: katzj at redhat.com (Jeremy Katz) Date: Mon, 26 Dec 2005 14:42:18 -0500 Subject: rawhide report: 20051226 changes In-Reply-To: <20051226193219.GA6070@redhat.com> References: <200512260812.jBQ8Cu3m007769@porkchop.devel.redhat.com> <20051226193219.GA6070@redhat.com> Message-ID: <1135626138.2752.30.camel@bree.local.net> On Mon, 2005-12-26 at 14:32 -0500, Dave Jones wrote: > On Mon, Dec 26, 2005 at 03:12:56AM -0500, Build System wrote: > > New package salinfo > > SAL info tool. > > Odd. This has been around for ages, (though I'm not entirely > sure why, as it's ia64 only, and of limited use). ia64 trees went kablooie for a few days (... part of why rawhide didn't go out) and I think the treediff went against a non-existent one, so all the ia64 only packages showed up as "new" > > Updated Packages: > > dmidecode-1:2.6-1.14 > > -------------------- > > * Fri Apr 15 2005 Florian La Roche > > - remove empty scripts > > > > * Wed Mar 02 2005 Dave Jones > > - Update to upstream 2.6 > > > > * Tue Mar 01 2005 Dave Jones > > - Rebuild for gcc4 > > rawhide also has dmidecode-2.7-1.22 > Why on earth did this ancient version pop up? This is the last version available for ia64 and cf above. Jeremy From fedora at iagorubio.com Mon Dec 26 20:44:50 2005 From: fedora at iagorubio.com (Iago Rubio) Date: Mon, 26 Dec 2005 21:44:50 +0100 Subject: Palm sync status? In-Reply-To: <20051224165546.7fab755f.zaitcev@redhat.com> References: <1135413325.3721.2.camel@rivendell.home.local> <1135432018.5814.14.camel@localhost.localdomain> <20051224165546.7fab755f.zaitcev@redhat.com> Message-ID: <1135629890.18919.28.camel@speedy.iagorubio.net> On Sat, 2005-12-24 at 16:55 -0800, Pete Zaitcev wrote: > On Sat, 24 Dec 2005 08:46:58 -0500, "Paul W. Frields" wrote: > > > > My Handspring Visor Platinum works with JPilot on FC4 provided that I > > > manually create the /dev/ttyUSB* files before each synchronization. > > > I fixed this problem some time ago, IIRC, by simply adding a file > > "/etc/udev/rules.d/95-visor.rules" that has just this line: > > > > KERNEL="ttyUSB1",SYMLINK="pilot" > > This seems to be a different problem, unless the other guy is not > seriously mistaken. In his case the original device nodes were not > created. > > > In the future, shouldn't these issues go to fedora-list and not > > fedora-devel-list? > > If we were talking about a proposed patch for udev, it would belong > here. I keep the hope. > > There would also be a significant development content if we dicussed > how to find a Pilot in a more robust way with udev. The thing is, > we cannot ship KERNEL="ttyUSB1", because of dynamic numbering. I've been gifted yesterday with a Palm Z22 and I've got it working with: BUS="usb", KERNEL="ttyUSB*", SYMLINK="pilot" I've also seen KERNEL="ttyUSB[13579]" all around on the net, so it seems the odd device - among the two created - is the one used to communicate with the pilot. The Z22 always picks the ttyUSB1 device. -- Iago Rubio From fedora at camperquake.de Mon Dec 26 20:51:32 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Mon, 26 Dec 2005 21:51:32 +0100 Subject: Palm sync status? In-Reply-To: <1135629890.18919.28.camel@speedy.iagorubio.net> References: <1135413325.3721.2.camel@rivendell.home.local> <1135432018.5814.14.camel@localhost.localdomain> <20051224165546.7fab755f.zaitcev@redhat.com> <1135629890.18919.28.camel@speedy.iagorubio.net> Message-ID: <20051226215132.35443831@nausicaa.camperquake.de> Hi. Iago Rubio wrote: > I've also seen KERNEL="ttyUSB[13579]" all around on the net, so it seems > the odd device - among the two created - is the one used to communicate > with the pilot. > > The Z22 always picks the ttyUSB1 device. That depends on how many USB/serial adapters you have inserted into the system at that time. From tgl at redhat.com Tue Dec 27 06:20:02 2005 From: tgl at redhat.com (Tom Lane) Date: Tue, 27 Dec 2005 01:20:02 -0500 Subject: Royalty free gstreamer plug-in In-Reply-To: <6b9c17630512260236vbb9d5a1l1aeffabcb7022b65@mail.gmail.com> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <1135352741.15650.54.camel@thomas.amantes> <43AC2336.3030909@n-man.com> <604aa7910512230826u4c22d27ftdfb051dd1605da18@mail.gmail.com> <43AC2674.6060601@n-man.com> <604aa7910512230857j12d52d0eo52e25a0877b4a4da@mail.gmail.com> <43AC2FA5.1030601@laposte.net> <6b9c17630512260236vbb9d5a1l1aeffabcb7022b65@mail.gmail.com> Message-ID: <20083.1135664402@sss.pgh.pa.us> Jeff Pitman writes: > (Optimally, FC should just take up the offer and include it in the > distro. Wasn't Redhat offering indemnication against ghost-cases of > patent claims during the SCO debacle? How about MP3? :D) IANAL, I don't speak for Red Hat, etc ... but a couple of points seem worth making here: 1. SCO's claims are utterly without merit. (IMHO, yadda yadda, see above.) The MP3 patents are real. 2. SCO's claims cover the basis of the Unix/Linux system, while the ability to play MP3's is, um, inessential to getting other things done. The risk/reward ratio for Red Hat to consider indemnifying users against the two issues is completely different. I don't think you'll see Red Hat going out on a limb for MP3 players. regards, tom lane From arjan at fenrus.demon.nl Tue Dec 27 07:49:03 2005 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Tue, 27 Dec 2005 08:49:03 +0100 Subject: Royalty free gstreamer plug-in In-Reply-To: <20083.1135664402@sss.pgh.pa.us> References: <43ABEF65.30707@nicubunu.ro> <1135348548.15650.41.camel@thomas.amantes> <43AC1869.1000803@n-man.com> <1135352741.15650.54.camel@thomas.amantes> <43AC2336.3030909@n-man.com> <604aa7910512230826u4c22d27ftdfb051dd1605da18@mail.gmail.com> <43AC2674.6060601@n-man.com> <604aa7910512230857j12d52d0eo52e25a0877b4a4da@mail.gmail.com> <43AC2FA5.1030601@laposte.net> <6b9c17630512260236vbb9d5a1l1aeffabcb7022b65@mail.gmail.com> <20083.1135664402@sss.pgh.pa.us> Message-ID: <1135669743.2926.9.camel@laptopd505.fenrus.org> On Tue, 2005-12-27 at 01:20 -0500, Tom Lane wrote: > Jeff Pitman writes: > > (Optimally, FC should just take up the offer and include it in the > > distro. Wasn't Redhat offering indemnication against ghost-cases of > > patent claims during the SCO debacle? How about MP3? :D) > > IANAL, I don't speak for Red Hat, etc ... but a couple of points seem > worth making here: > > 1. SCO's claims are utterly without merit. (IMHO, yadda yadda, see > above.) The MP3 patents are real. > > 2. SCO's claims cover the basis of the Unix/Linux system, while the > ability to play MP3's is, um, inessential to getting other things done. > > The risk/reward ratio for Red Hat to consider indemnifying users against > the two issues is completely different. I don't think you'll see Red > Hat going out on a limb for MP3 players. I also think that the indemnification only applies to paying customers (eg RHEL) and not fedora... From fedora at iagorubio.com Tue Dec 27 08:52:03 2005 From: fedora at iagorubio.com (Iago Rubio) Date: Tue, 27 Dec 2005 09:52:03 +0100 Subject: Palm sync status? In-Reply-To: <20051226215132.35443831@nausicaa.camperquake.de> References: <1135413325.3721.2.camel@rivendell.home.local> <1135432018.5814.14.camel@localhost.localdomain> <20051224165546.7fab755f.zaitcev@redhat.com> <1135629890.18919.28.camel@speedy.iagorubio.net> <20051226215132.35443831@nausicaa.camperquake.de> Message-ID: <1135673524.18919.51.camel@speedy.iagorubio.net> On Mon, 2005-12-26 at 21:51 +0100, Ralf Ertzinger wrote: > Hi. > > Iago Rubio wrote: > > > I've also seen KERNEL="ttyUSB[13579]" all around on the net, so it seems > > the odd device - among the two created - is the one used to communicate > > with the pilot. > > > > The Z22 always picks the ttyUSB1 device. > > That depends on how many USB/serial adapters you have inserted into the > system at that time. Yes, I know :) I meant it always picks the ttyUSB1 among ttyUSB0 and ttyUSB1, so it always picks the odd device. -- Iago Rubio From buildsys at redhat.com Tue Dec 27 09:13:11 2005 From: buildsys at redhat.com (Build System) Date: Tue, 27 Dec 2005 04:13:11 -0500 Subject: rawhide report: 20051227 changes Message-ID: <200512270913.jBR9DBbg015227@porkchop.devel.redhat.com> Updated Packages: scim-tables-0.5.5-2 ------------------- * Mon Dec 26 2005 Jens Petersen - 0.5.5-2 - remove the Japanese and Korean tables and their subpackages Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.2.i686 requires /lib/modules/2.6.14-1.1775_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.2.i686 requires kernel = 0:2.6.14-1.1775_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.2.i686 requires kernel-smp = 0:2.6.14-1.1775_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.2.i686 requires /lib/modules/2.6.14-1.1775_FC5smp cman-kernel - 2.6.14.1-20051219.162641.FC5.3.i686 requires /lib/modules/2.6.14-1.1775_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.3.i686 requires kernel = 0:2.6.14-1.1775_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.3.i686 requires kernel-smp = 0:2.6.14-1.1775_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.3.i686 requires /lib/modules/2.6.14-1.1775_FC5smp dlm-kernel - 2.6.14.1-20051219.162641.FC5.3.i686 requires /lib/modules/2.6.14-1.1783_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.3.i686 requires kernel = 0:2.6.14-1.1783_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.3.i686 requires /lib/modules/2.6.14-1.1783_FC5smp dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.3.i686 requires kernel-smp = 0:2.6.14-1.1783_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.4.i686 requires /lib/modules/2.6.14-1.1777_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.4.i686 requires kernel = 0:2.6.14-1.1777_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.4.i686 requires /lib/modules/2.6.14-1.1777_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.4.i686 requires kernel-smp = 0:2.6.14-1.1777_FC5 jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 Broken deps for ia64 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) Broken deps for s390 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 Broken deps for s390x ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.2.x86_64 requires /lib/modules/2.6.14-1.1775_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.2.x86_64 requires kernel = 0:2.6.14-1.1775_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.3.x86_64 requires /lib/modules/2.6.14-1.1775_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.3.x86_64 requires kernel = 0:2.6.14-1.1775_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.3.x86_64 requires /lib/modules/2.6.14-1.1783_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.3.x86_64 requires kernel = 0:2.6.14-1.1783_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.4.x86_64 requires /lib/modules/2.6.14-1.1777_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.4.x86_64 requires kernel = 0:2.6.14-1.1777_FC5 jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) From jeff.pitman at gmail.com Tue Dec 27 09:58:36 2005 From: jeff.pitman at gmail.com (Jeff Pitman) Date: Tue, 27 Dec 2005 17:58:36 +0800 Subject: Royalty free gstreamer plug-in In-Reply-To: <20083.1135664402@sss.pgh.pa.us> References: <43AC1869.1000803@n-man.com> <1135352741.15650.54.camel@thomas.amantes> <43AC2336.3030909@n-man.com> <604aa7910512230826u4c22d27ftdfb051dd1605da18@mail.gmail.com> <43AC2674.6060601@n-man.com> <604aa7910512230857j12d52d0eo52e25a0877b4a4da@mail.gmail.com> <43AC2FA5.1030601@laposte.net> <6b9c17630512260236vbb9d5a1l1aeffabcb7022b65@mail.gmail.com> <20083.1135664402@sss.pgh.pa.us> Message-ID: <6b9c17630512270158t66208cd2l8efeec05aa6a6e78@mail.gmail.com> On 12/27/05, Tom Lane wrote: > The risk/reward ratio for Red Hat to consider indemnifying users against > the two issues is completely different. I don't think you'll see Red > Hat going out on a limb for MP3 players. IOW, indemnification offers are just hot air. But, we know this isn't indemnification for MP3s, it's a different beast. The comment was to highlight where Redhat's priorities are. For good or bad. Let's not forget that the "holier-than-thou" stance alienates quite a few users. -- -jeff From sundaram at redhat.com Tue Dec 27 10:13:38 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Tue, 27 Dec 2005 15:43:38 +0530 Subject: Royalty free gstreamer plug-in In-Reply-To: <6b9c17630512270158t66208cd2l8efeec05aa6a6e78@mail.gmail.com> References: <43AC1869.1000803@n-man.com> <1135352741.15650.54.camel@thomas.amantes> <43AC2336.3030909@n-man.com> <604aa7910512230826u4c22d27ftdfb051dd1605da18@mail.gmail.com> <43AC2674.6060601@n-man.com> <604aa7910512230857j12d52d0eo52e25a0877b4a4da@mail.gmail.com> <43AC2FA5.1030601@laposte.net> <6b9c17630512260236vbb9d5a1l1aeffabcb7022b65@mail.gmail.com> <20083.1135664402@sss.pgh.pa.us> <6b9c17630512270158t66208cd2l8efeec05aa6a6e78@mail.gmail.com> Message-ID: <43B113D2.4040102@redhat.com> Jeff Pitman wrote: >On 12/27/05, Tom Lane wrote: > > >>The risk/reward ratio for Red Hat to consider indemnifying users against >>the two issues is completely different. I don't think you'll see Red >>Hat going out on a limb for MP3 players. >> >> > >IOW, indemnification offers are just hot air. But, we know this isn't >indemnification for MP3s, it's a different beast. The comment was to >highlight where Redhat's priorities are. For good or bad. > >Let's not forget that the "holier-than-thou" stance alienates quite a few users. > > > Can you explain that comment a bit more?. Do you mean the stance on providing only open source software without restrictions? -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From Nicolas.Mailhot at laPoste.net Tue Dec 27 12:53:18 2005 From: Nicolas.Mailhot at laPoste.net (Nicolas Mailhot) Date: Tue, 27 Dec 2005 13:53:18 +0100 Subject: Royalty free gstreamer plug-in In-Reply-To: <6b9c17630512270158t66208cd2l8efeec05aa6a6e78@mail.gmail.com> References: <43AC1869.1000803@n-man.com> <1135352741.15650.54.camel@thomas.amantes> <43AC2336.3030909@n-man.com> <604aa7910512230826u4c22d27ftdfb051dd1605da18@mail.gmail.com> <43AC2674.6060601@n-man.com> <604aa7910512230857j12d52d0eo52e25a0877b4a4da@mail.gmail.com> <43AC2FA5.1030601@laposte.net> <6b9c17630512260236vbb9d5a1l1aeffabcb7022b65@mail.gmail.com> <20083.1135664402@sss.pgh.pa.us> <6b9c17630512270158t66208cd2l8efeec05aa6a6e78@mail.gmail.com> Message-ID: <43B1393E.5070601@laPoste.net> Jeff Pitman a ?crit : > Let's not forget that the "holier-than-thou" stance alienates quite a few users. And the permissive attitude of some distributions alienate others. Fedora has to take one side on the IP rights debate. And no matter which one is it, people on the other side will be "alienated" by this choice. I don't think we need another Mandriva/Linspire in the Linux world. -- Nicolas Mailhot From jeff.pitman at gmail.com Tue Dec 27 13:54:14 2005 From: jeff.pitman at gmail.com (Jeff Pitman) Date: Tue, 27 Dec 2005 21:54:14 +0800 Subject: Royalty free gstreamer plug-in In-Reply-To: <43B113D2.4040102@redhat.com> References: <43AC2336.3030909@n-man.com> <604aa7910512230826u4c22d27ftdfb051dd1605da18@mail.gmail.com> <43AC2674.6060601@n-man.com> <604aa7910512230857j12d52d0eo52e25a0877b4a4da@mail.gmail.com> <43AC2FA5.1030601@laposte.net> <6b9c17630512260236vbb9d5a1l1aeffabcb7022b65@mail.gmail.com> <20083.1135664402@sss.pgh.pa.us> <6b9c17630512270158t66208cd2l8efeec05aa6a6e78@mail.gmail.com> <43B113D2.4040102@redhat.com> Message-ID: <6b9c17630512270554p341011bepbce668c3f844be9b@mail.gmail.com> On 12/27/05, Rahul Sundaram wrote: > Jeff Pitman wrote: > >Let's not forget that the "holier-than-thou" stance alienates quite a few users. > > > Can you explain that comment a bit more?. Sure, no problem. > Do you mean the stance on providing only open source software without restrictions? Yes. And that's not to say that I disagree with the stance. In fact, I agree with it given that "restrictions" are well-defined. Being belligerent about looking into potential workarounds is not a show of good faith. And, when you do not show good faith, you lose people. Maybe you don't care; that's fine. But, it's good to be reminded that the stances we take can and will alienate a bunch of people. It's the truth whether you "much rather change the world instead of going along with it" or not. -- -jeff From sundaram at redhat.com Tue Dec 27 14:04:09 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Tue, 27 Dec 2005 19:34:09 +0530 Subject: Royalty free gstreamer plug-in In-Reply-To: <6b9c17630512270554p341011bepbce668c3f844be9b@mail.gmail.com> References: <43AC2336.3030909@n-man.com> <604aa7910512230826u4c22d27ftdfb051dd1605da18@mail.gmail.com> <43AC2674.6060601@n-man.com> <604aa7910512230857j12d52d0eo52e25a0877b4a4da@mail.gmail.com> <43AC2FA5.1030601@laposte.net> <6b9c17630512260236vbb9d5a1l1aeffabcb7022b65@mail.gmail.com> <20083.1135664402@sss.pgh.pa.us> <6b9c17630512270158t66208cd2l8efeec05aa6a6e78@mail.gmail.com> <43B113D2.4040102@redhat.com> <6b9c17630512270554p341011bepbce668c3f844be9b@mail.gmail.com> Message-ID: <43B149D9.9070907@redhat.com> Hi > > > >>Do you mean the stance on providing only open source software without restrictions? >> >> > >Yes. And that's not to say that I disagree with the stance. In fact, I >agree with it given that "restrictions" are well-defined. > Right. The restrictions are pretty well defined at this point. The project goals are well advertised and active on the lists I believe knows about it. >Being >belligerent about looking into potential workarounds is not a show of >good faith. And, when you do not show good faith, you lose people. >Maybe you don't care; that's fine. But, it's good to be reminded that >the stances we take can and will alienate a bunch of people. It's the >truth whether you "much rather change the world instead of going along >with it" or not. >-- > How is a Free and open source stance not showing good faith? . There are over seventy distributions based on Fedora. Its not religion or whims. Yes it will alienate a few proprietary software supporters who will have to get the software from elsewhere. What exactly is your solution that you are suggesting?. Vague notions dont help resolve anything. -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From fedora at camperquake.de Tue Dec 27 14:14:19 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Tue, 27 Dec 2005 15:14:19 +0100 Subject: udev makes /dev/raw1394, but no module In-Reply-To: References: <20051224165813.009ef0b0.zaitcev@redhat.com> Message-ID: <20051227141418.GA20646@ryoko.camperquake.de> On Sun, Dec 25, 2005 at 02:49:38PM -0800, sean darcy wrote: > Maybe, but modprobe raw1394 works, and does not return any error. In > fact, the way I've hacked this is just to modprobe the 1394 modules in > rc.local, which works just fine. This affects everything FireWire, sdp2 (storage) is not autoloaded, too. Looks like the firewire driver does not hand out hotplug events anymore. Manually loading the module works just fine and gets attached drives going. From jeff.pitman at gmail.com Tue Dec 27 14:17:05 2005 From: jeff.pitman at gmail.com (Jeff Pitman) Date: Tue, 27 Dec 2005 22:17:05 +0800 Subject: Royalty free gstreamer plug-in In-Reply-To: <43B149D9.9070907@redhat.com> References: <43AC2674.6060601@n-man.com> <604aa7910512230857j12d52d0eo52e25a0877b4a4da@mail.gmail.com> <43AC2FA5.1030601@laposte.net> <6b9c17630512260236vbb9d5a1l1aeffabcb7022b65@mail.gmail.com> <20083.1135664402@sss.pgh.pa.us> <6b9c17630512270158t66208cd2l8efeec05aa6a6e78@mail.gmail.com> <43B113D2.4040102@redhat.com> <6b9c17630512270554p341011bepbce668c3f844be9b@mail.gmail.com> <43B149D9.9070907@redhat.com> Message-ID: <6b9c17630512270617k70a986c0y4d960547674aa9a@mail.gmail.com> On 12/27/05, Rahul Sundaram wrote: > What exactly is your > solution that you are suggesting? If Redhat is unwilling to signup to Fluendo's free-of-charge, open source, but not entirely free software deal, that's understandable. At least provide explicit instructions on how to get MP3 bootstrapped so as to attract and retain new users. Instead of some vague FAQ in the About page of Fedora. Maybe put in a yum.repos.d config commented out that would allow easy installation with a disclaimer comment. You know, user-oriented stuff. -- -jeff From sundaram at redhat.com Tue Dec 27 14:25:54 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Tue, 27 Dec 2005 19:55:54 +0530 Subject: Royalty free gstreamer plug-in In-Reply-To: <6b9c17630512270617k70a986c0y4d960547674aa9a@mail.gmail.com> References: <43AC2674.6060601@n-man.com> <604aa7910512230857j12d52d0eo52e25a0877b4a4da@mail.gmail.com> <43AC2FA5.1030601@laposte.net> <6b9c17630512260236vbb9d5a1l1aeffabcb7022b65@mail.gmail.com> <20083.1135664402@sss.pgh.pa.us> <6b9c17630512270158t66208cd2l8efeec05aa6a6e78@mail.gmail.com> <43B113D2.4040102@redhat.com> <6b9c17630512270554p341011bepbce668c3f844be9b@mail.gmail.com> <43B149D9.9070907@redhat.com> <6b9c17630512270617k70a986c0y4d960547674aa9a@mail.gmail.com> Message-ID: <43B14EF2.9060303@redhat.com> Jeff Pitman wrote: >On 12/27/05, Rahul Sundaram wrote: > > >>What exactly is your >>solution that you are suggesting? >> >> > >If Redhat is unwilling to signup to Fluendo's free-of-charge, open >source, but not entirely free software deal, that's understandable. At >least provide explicit instructions on how to get MP3 bootstrapped so >as to attract and retain new users. > This is a potential solution but one that requires careful thought. > Instead of some vague FAQ in the >About page of Fedora. Maybe put in a yum.repos.d config commented out >that would allow easy installation with a disclaimer comment. You >know, user-oriented stuff. > > How do you know about the legal implications of this?. Does it suit the project goals?. Like I said before halting the discussion now and taking it to the legal team would be the right solution. Be patient before putting in references to SCO which isnt the same thing at all. -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From jeff.pitman at gmail.com Tue Dec 27 14:30:58 2005 From: jeff.pitman at gmail.com (Jeff Pitman) Date: Tue, 27 Dec 2005 22:30:58 +0800 Subject: Royalty free gstreamer plug-in In-Reply-To: <43B14EF2.9060303@redhat.com> References: <43AC2FA5.1030601@laposte.net> <6b9c17630512260236vbb9d5a1l1aeffabcb7022b65@mail.gmail.com> <20083.1135664402@sss.pgh.pa.us> <6b9c17630512270158t66208cd2l8efeec05aa6a6e78@mail.gmail.com> <43B113D2.4040102@redhat.com> <6b9c17630512270554p341011bepbce668c3f844be9b@mail.gmail.com> <43B149D9.9070907@redhat.com> <6b9c17630512270617k70a986c0y4d960547674aa9a@mail.gmail.com> <43B14EF2.9060303@redhat.com> Message-ID: <6b9c17630512270630k411c2465qf2cd90670e0f6870@mail.gmail.com> On 12/27/05, Rahul Sundaram wrote: > How do you know about the legal implications of this?. Does it suit the > project goals?. Like I said before halting the discussion now and taking > it to the legal team would be the right solution. Be patient before > putting in references to SCO which isnt the same thing at all. Not sure, but I agree, it needs some thought. -- -jeff From seandarcy2 at gmail.com Tue Dec 27 18:22:10 2005 From: seandarcy2 at gmail.com (sean darcy) Date: Tue, 27 Dec 2005 10:22:10 -0800 Subject: udev makes /dev/raw1394, but no module In-Reply-To: <20051227141418.GA20646@ryoko.camperquake.de> References: <20051224165813.009ef0b0.zaitcev@redhat.com> <20051227141418.GA20646@ryoko.camperquake.de> Message-ID: Ralf Ertzinger wrote: > On Sun, Dec 25, 2005 at 02:49:38PM -0800, sean darcy wrote: > > >>Maybe, but modprobe raw1394 works, and does not return any error. In >>fact, the way I've hacked this is just to modprobe the 1394 modules in >>rc.local, which works just fine. > > > This affects everything FireWire, sdp2 (storage) is not autoloaded, too. > Looks like the firewire driver does not hand out hotplug events anymore. > Manually loading the module works just fine and gets attached drives going. > Actually it does. I got this from the kino list: ieee1394 on kernel 2.6 was not exporting enough information within /sys in order to make udev a viable solution to this until kernel 2.6.12. There is a simple example udev rules configuration on linux1394.org if you have 2.6.12 or newer. However, udev rules can be slightly different Maybe someone who knows udev could see if these could work for fc5? sean From vonbrand at inf.utfsm.cl Tue Dec 27 18:24:16 2005 From: vonbrand at inf.utfsm.cl (Horst von Brand) Date: Tue, 27 Dec 2005 15:24:16 -0300 Subject: Royalty free gstreamer plug-in In-Reply-To: Your message of "Tue, 27 Dec 2005 17:58:36 +0800." <6b9c17630512270158t66208cd2l8efeec05aa6a6e78@mail.gmail.com> Message-ID: <200512271824.jBRIOGoP018227@laptop11.inf.utfsm.cl> Jeff Pitman wrote: > On 12/27/05, Tom Lane wrote: > > The risk/reward ratio for Red Hat to consider indemnifying users against > > the two issues is completely different. I don't think you'll see Red > > Hat going out on a limb for MP3 players. > IOW, indemnification offers are just hot air. No, they aren't. Sure, Red Hat counts on never to have to pay out, but the offer is still good (and gives the people on the other end of it a bit of reassurance, which is exactly the point). > But, we know this isn't > indemnification for MP3s, it's a different beast. Why, you can sure get them. I.e., if you are liable to pay $$$ for using MP3 without a valid license, I'd be happy to give you an indemnification offer paying your costs (if it comes that far) for the very reasonable amount of 2 x $$$ (to cover taxes, expenses, my own liability in this, ...). Deal? > The comment was to > highlight where Redhat's priorities are. For good or bad. No need to point them out here, except for trolling. > Let's not forget that the "holier-than-thou" stance alienates quite a few > users. So what? Fedora has its guidelines and goals, which include this "stance" as you paint it. If you don't agree, either get elected as officer in the relevant place to change it, or go elsewhere. It's a free world. -- Dr. Horst H. von Brand User #22616 counter.li.org Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513 From mandreiana.lists at gmail.com Tue Dec 27 20:54:29 2005 From: mandreiana.lists at gmail.com (Marius Andreiana) Date: Tue, 27 Dec 2005 22:54:29 +0200 Subject: Status of docbook to pdf toolchain on Fedora? In-Reply-To: <43A9FD31.9030903@research.att.com> References: <43A99EF3.9050404@research.att.com> <20051221214325.GG16000@redhat.com> <1135207981.25397.31.camel@cassandra.boston.redhat.com> <43A9FD31.9030903@research.att.com> Message-ID: <1135716869.3345.3.camel@mariusa-ro.ro.oracle.com> On Wed, 2005-12-21 at 20:11 -0500, John Ellson wrote: > David Malcolm wrote: > > On Wed, 2005-12-21 at 21:43 +0000, Tim Waugh wrote: > > > >> On Wed, Dec 21, 2005 at 01:29:07PM -0500, John Ellson wrote: > >> > >> > >>> I gather from a 2004 thread in fedora-docs-list that the toolchain was > >>> moving to fop, > >>> but I don't see any fop yet in core or extras. > >>> > I grabbed the latest FOP trunk from svn, but it still seems to have Sun > dependencies. There is an C alternative to FOP: http://xmlroff.sourceforge.net/news.html xmlroff (http://xmlroff.org) is an XSL Formatter written in C that produces PDF and PostScript. xmlroff 0.3.0 builds solely on open source software since it no longer supports a PDFlib backend. It also plays well with GNOME desktops since it uses Pango and the new PangoXSL library As I don't use XSLFO now, but I did in the past with FOP, I didn't test this, but looks more attractive and lightweight (libxslt philosophy) than FOP. -- Marius Andreiana From ellson at research.att.com Wed Dec 28 05:11:52 2005 From: ellson at research.att.com (John Ellson) Date: Wed, 28 Dec 2005 00:11:52 -0500 Subject: Status of docbook to pdf toolchain on Fedora? In-Reply-To: <1135716869.3345.3.camel@mariusa-ro.ro.oracle.com> References: <43A99EF3.9050404@research.att.com> <20051221214325.GG16000@redhat.com> <1135207981.25397.31.camel@cassandra.boston.redhat.com> <43A9FD31.9030903@research.att.com> <1135716869.3345.3.camel@mariusa-ro.ro.oracle.com> Message-ID: <43B21E98.7010703@research.att.com> Marius Andreiana wrote: > On Wed, 2005-12-21 at 20:11 -0500, John Ellson wrote: > >> David Malcolm wrote: >> >>> On Wed, 2005-12-21 at 21:43 +0000, Tim Waugh wrote: >>> >>> >>>> On Wed, Dec 21, 2005 at 01:29:07PM -0500, John Ellson wrote: >>>> >>>> >>>> >>>>> I gather from a 2004 thread in fedora-docs-list that the toolchain was >>>>> moving to fop, >>>>> but I don't see any fop yet in core or extras. >>>>> >>>>> >> I grabbed the latest FOP trunk from svn, but it still seems to have >> > Sun > >> dependencies. >> > > There is an C alternative to FOP: > http://xmlroff.sourceforge.net/news.html > > xmlroff (http://xmlroff.org) is an XSL Formatter written in C that > produces PDF and PostScript. xmlroff 0.3.0 builds solely on open source > software since it no longer supports a PDFlib backend. It also plays > well with GNOME desktops since it uses Pango and the new PangoXSL > library > Thanks for the reference. Unfortunately it depends on pangoxsl which hasn't been maintained since March. I can't trivially get it to build on fedora-core-development. Perhaps I'll try a bit harder tomorrow. John > As I don't use XSLFO now, but I did in the past with FOP, I didn't test > this, but looks more attractive and lightweight (libxslt philosophy) > than FOP. > > From buildsys at redhat.com Wed Dec 28 08:01:25 2005 From: buildsys at redhat.com (Build System) Date: Wed, 28 Dec 2005 03:01:25 -0500 Subject: rawhide report: 20051228 changes Message-ID: <200512280801.jBS81P7u002778@porkchop.devel.redhat.com> Updated Packages: GFS-kernel-2.6.14.1-20051219.162641.FC5.5 ----------------------------------------- * Tue Dec 27 2005 Jesse Keating - rebuilt cman-kernel-2.6.14.1-20051219.162641.FC5.4 ------------------------------------------ * Tue Dec 27 2005 Jesse Keating - rebuilt * Mon Dec 19 2005 Chris Feist - Updated upstream sources. * Fri Dec 09 2005 Jesse Keating - rebuilt dlm-kernel-2.6.14.1-20051219.162641.FC5.4 ----------------------------------------- * Tue Dec 27 2005 Jesse Keating - rebuilt gnbd-kernel-2.6.14.0-20051108.134753.FC5.12.27 ---------------------------------------------- * Tue Dec 27 2005 Jesse Keating - rebuilt kernel-2.6.14-1.1788_FC5 ------------------------ * Tue Dec 27 2005 Dave Jones - 2.6.15-rc7-git1 selinux-policy-2.1.6-17 ----------------------- * Tue Dec 27 2005 Dan Walsh 2.1.6-17 - Fix library specification - Give kudzu execmem privs Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.5.i686 requires kernel = 0:2.6.14-1.1786_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.5.i686 requires /lib/modules/2.6.14-1.1786_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.5.i686 requires /lib/modules/2.6.14-1.1786_FC5smp GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.5.i686 requires kernel-smp = 0:2.6.14-1.1786_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.4.i686 requires kernel = 0:2.6.14-1.1786_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.4.i686 requires /lib/modules/2.6.14-1.1786_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.4.i686 requires /lib/modules/2.6.14-1.1786_FC5smp cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.4.i686 requires kernel-smp = 0:2.6.14-1.1786_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.4.i686 requires kernel = 0:2.6.14-1.1786_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.4.i686 requires /lib/modules/2.6.14-1.1786_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.4.i686 requires /lib/modules/2.6.14-1.1786_FC5smp dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.4.i686 requires kernel-smp = 0:2.6.14-1.1786_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.27.i686 requires kernel = 0:2.6.14-1.1786_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.27.i686 requires /lib/modules/2.6.14-1.1786_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.27.i686 requires /lib/modules/2.6.14-1.1786_FC5smp gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.27.i686 requires kernel-smp = 0:2.6.14-1.1786_FC5 jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 Broken deps for ia64 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) Broken deps for s390 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 systemtap - 0.5.2-2.s390 requires kernel >= 0:2.6.9-11 systemtap - 0.5.2-2.s390 requires kernel-devel Broken deps for s390x ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) systemtap - 0.5.2-2.s390x requires kernel >= 0:2.6.9-11 systemtap - 0.5.2-2.s390x requires kernel-devel Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.5.x86_64 requires kernel = 0:2.6.14-1.1786_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.5.x86_64 requires /lib/modules/2.6.14-1.1786_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.4.x86_64 requires kernel = 0:2.6.14-1.1786_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.4.x86_64 requires /lib/modules/2.6.14-1.1786_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.4.x86_64 requires kernel = 0:2.6.14-1.1786_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.4.x86_64 requires /lib/modules/2.6.14-1.1786_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.27.x86_64 requires kernel = 0:2.6.14-1.1786_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.27.x86_64 requires /lib/modules/2.6.14-1.1786_FC5 jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) From pjones at redhat.com Wed Dec 28 08:41:37 2005 From: pjones at redhat.com (Peter Jones) Date: Wed, 28 Dec 2005 03:41:37 -0500 Subject: how does selinux get initialized durring bootup? In-Reply-To: <43AD0828.5060605@feuerpokemon.de> References: <43AD0828.5060605@feuerpokemon.de> Message-ID: <1135759297.25959.12.camel@localhost.localdomain> On Sat, 2005-12-24 at 09:34 +0100, dragoran wrote: > as you can see here: > http://bugzilla.initng.thinktux.net/show_bug.cgi?id=365 > there is a bug in initng that after booting selinux is not working. > what needs to be done in the boot process to get selinux working ? > have searched in the initscripts and have'nt found anything that helps. init needs to load the policy. Read the SysVinit code for details. -- Peter From bojan at rexursive.com Wed Dec 28 10:39:50 2005 From: bojan at rexursive.com (Bojan Smojver) Date: Wed, 28 Dec 2005 21:39:50 +1100 Subject: Random X crashes: fact or fiction? Message-ID: <1135766390.2682.6.camel@coyote.rexursive.com> Just had another crash. Same scenario: kernel compile, browsing, e-mail etc. BTW, I have two pointers: Synaptics touchpad and a PS/2 mouse. Is it possible for X to go haywire if it can't talk to its CorePointer (touchpad)? Maybe under heavy load things become "slow" on that front and X interprets that as no pointer? X does get confused when the mouse is plugged in while X is starting and then it won't run at all. It claims that CorePointer isn't there. Weird... -- Bojan From igorm5 at vip.hr Wed Dec 28 10:45:15 2005 From: igorm5 at vip.hr (Igor Jagec) Date: Wed, 28 Dec 2005 11:45:15 +0100 Subject: Can't upgrade to Rawhide Message-ID: <43B26CBB.5080105@vip.hr> I'm trying to upgrade to Rawhide from fully updated FC4 on my test partition for quite some time, but I never manage to succeed it. Yum constantly give me some errors, such as: ... --> Running transaction check --> Processing Conflict: initscripts conflicts kernel < 2.6.12 --> Processing Conflict: kudzu conflicts kernel < 2.6.13 --> Processing Dependency: python = 2.4.1 for package: smart --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. --> Running transaction check --> Processing Conflict: initscripts conflicts kernel < 2.6.12 --> Processing Conflict: kudzu conflicts kernel < 2.6.13 --> Processing Dependency: python = 2.4.1 for package: smart --> Restarting Dependency Resolution with new changes. --> Populating transaction set with selected packages. Please wait. --> Running transaction check Error: Missing Dependency: python = 2.4.1 is needed by package smart Error: Unable to satisfy dependencies Error: Package initscripts needs kernel < 2.6.12, this is not available. Error: Package kudzu needs kernel < 2.6.13, this is not available. Error: Package smart needs python = 2.4.1, this is not available. ------------------------------------------------------------------------ Is there any way to fix that manually? Is it possible to access to Rawhide via SmartPM? If so, what channel would that be? Thanks, cheers! -- Igor Jagec From micwise at bellsouth.net Wed Dec 28 11:48:32 2005 From: micwise at bellsouth.net (Michael D. Wise) Date: Wed, 28 Dec 2005 05:48:32 -0600 Subject: Can't upgrade to Rawhide In-Reply-To: <43B26CBB.5080105@vip.hr> References: <43B26CBB.5080105@vip.hr> Message-ID: <1135770512.7725.3.camel@stonewall.northforty.net> On Wed, 2005-12-28 at 11:45 +0100, Igor Jagec wrote: > I'm trying to upgrade to Rawhide from fully updated FC4 on my test > partition for quite some time, but I never manage to succeed it. Yum > constantly give me some errors, such as: > > ... > --> Running transaction check > --> Processing Conflict: initscripts conflicts kernel < 2.6.12 > --> Processing Conflict: kudzu conflicts kernel < 2.6.13 > --> Processing Dependency: python = 2.4.1 for package: smart > --> Restarting Dependency Resolution with new changes. > --> Populating transaction set with selected packages. Please wait. > --> Running transaction check > --> Processing Conflict: initscripts conflicts kernel < 2.6.12 > --> Processing Conflict: kudzu conflicts kernel < 2.6.13 > --> Processing Dependency: python = 2.4.1 for package: smart > --> Restarting Dependency Resolution with new changes. > --> Populating transaction set with selected packages. Please wait. > --> Running transaction check > Error: Missing Dependency: python = 2.4.1 is needed by package smart > Error: Unable to satisfy dependencies > Error: Package initscripts needs kernel < 2.6.12, this is not available. > Error: Package kudzu needs kernel < 2.6.13, this is not available. > Error: Package smart needs python = 2.4.1, this is not available. > ------------------------------------------------------------------------ > > Is there any way to fix that manually? Is it possible to access to > Rawhide via SmartPM? If so, what channel would that be? You need to remove all installed kernel versions less that 2.6.14. That should fix you initscripts and kudzu conflicts. I don't know what that smart package is but it looks like you need to upgrade that as well before you can upgrade python. Michael -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. From jeff.pitman at gmail.com Wed Dec 28 11:52:51 2005 From: jeff.pitman at gmail.com (Jeff Pitman) Date: Wed, 28 Dec 2005 19:52:51 +0800 Subject: RPM Packaging and Python Eggs Message-ID: <6b9c17630512280352h68047491xd7f7d6215e63525@mail.gmail.com> Hi, Just wanted to share this. As the Python Eggs concept proliferates, there is an option to bypass the whole mess: --old-and-unmanageable. This could be used as an alternative to patching setup.py to point to the old distutils. So: %{__python} setup.py install --root=$RPM_BUILD_ROOT Becomes: %{__python} setup.py install --old-and-unmanageable --root=$RPM_BUILD_ROOT Obviously, this breaks if it's a regular distutils setup.py. And, what makes it more fun is that Py2.2 doesn't work. So, patching might be the best when you care about that. If you're guaranteed that the spec is only forward moving (ie extras and rawhide), then the option above will work and make the spec cleaner. While I've written off Eggs as a way to manage system-level python lib packages, it may be useful for managing pkgs in $HOME for multi-user systems. Thoughts? -- -jeff From ivazquez at ivazquez.net Wed Dec 28 12:03:48 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Wed, 28 Dec 2005 07:03:48 -0500 Subject: RPM Packaging and Python Eggs In-Reply-To: <6b9c17630512280352h68047491xd7f7d6215e63525@mail.gmail.com> References: <6b9c17630512280352h68047491xd7f7d6215e63525@mail.gmail.com> Message-ID: <1135771428.15008.9.camel@ignacio.lan> On Wed, 2005-12-28 at 19:52 +0800, Jeff Pitman wrote: > While I've written off Eggs as a way to manage system-level python lib > packages, it may be useful for managing pkgs in $HOME for multi-user > systems. Thoughts? While they may be overkill that certainly doesn't mean they're useless. As more and more Python libraries migrate to using eggs it's going to become less convenient to have to futz with every setup.py file just to comment out the libraries that don't have eggs. -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- 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 mukund.miscregisters at gmail.com Wed Dec 28 12:21:02 2005 From: mukund.miscregisters at gmail.com (mukund jampala) Date: Wed, 28 Dec 2005 17:51:02 +0530 Subject: FC4 hangs when trying to boot after "enabling the span space" Message-ID: Dear FC4 Devel & Users, The Fedora C4 hangs when trying to boot after "enabling the span space". Can someone suggest me the problem area? Regards, Mukund Jampala From mukund.miscregisters at gmail.com Wed Dec 28 12:41:33 2005 From: mukund.miscregisters at gmail.com (mukund jampala) Date: Wed, 28 Dec 2005 18:11:33 +0530 Subject: FC4 hangs after "ata2: disabling port" Message-ID: Dear FC4 devels & Users, The Fedora C4 hangs when trying to boot exactly after "enabling the swap space [ok] ". I guess swap space is enabled properly with 'OK' message. The system has 2 SATA disks. I have installed FC4 on /dec/sdb2 (part 2 of disk2). I suspect there is some problem that the following kernel message is trying to tell: ata2: disabling port INIT: version 2.85 booting Can some one please elobarate on what exactly could be the problem? Regards, Mukund Jampala From brilong at cisco.com Wed Dec 28 13:09:16 2005 From: brilong at cisco.com (Brian Long) Date: Wed, 28 Dec 2005 08:09:16 -0500 Subject: Can't upgrade to Rawhide In-Reply-To: <43B26CBB.5080105@vip.hr> References: <43B26CBB.5080105@vip.hr> Message-ID: <1135775356.4574.8.camel@brilong-lnx> On Wed, 2005-12-28 at 11:45 +0100, Igor Jagec wrote: > I'm trying to upgrade to Rawhide from fully updated FC4 on my test > partition for quite some time, but I never manage to succeed it. Yum > constantly give me some errors, such as: > > ... > --> Running transaction check > --> Processing Conflict: initscripts conflicts kernel < 2.6.12 Remove the old 2.6.11 FC4 kernel. > --> Processing Conflict: kudzu conflicts kernel < 2.6.13 Remove the old 2.6.12 FC4 kernel. > --> Processing Dependency: python = 2.4.1 for package: smart I am not familiar with this package. If you're not using it, remove it. After following these steps, the upgrade should go smoothly. /Brian/ -- Brian Long | | | IT Data Center Systems | .|||. .|||. Cisco Linux Developer | ..:|||||||:...:|||||||:.. Phone: (919) 392-7363 | C i s c o S y s t e m s From sundaram at redhat.com Wed Dec 28 15:29:33 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Wed, 28 Dec 2005 20:59:33 +0530 Subject: Can't upgrade to Rawhide In-Reply-To: <43B26CBB.5080105@vip.hr> References: <43B26CBB.5080105@vip.hr> Message-ID: <43B2AF5D.9030408@redhat.com> Igor Jagec wrote: >I'm trying to upgrade to Rawhide from fully updated FC4 on my test >partition for quite some time, but I never manage to succeed it. Yum >constantly give me some errors, such as: > >... >--> Running transaction check >--> Processing Conflict: initscripts conflicts kernel < 2.6.12 >--> Processing Conflict: kudzu conflicts kernel < 2.6.13 >--> Processing Dependency: python = 2.4.1 for package: smart >--> Restarting Dependency Resolution with new changes. >--> Populating transaction set with selected packages. Please wait. >--> Running transaction check >--> Processing Conflict: initscripts conflicts kernel < 2.6.12 >--> Processing Conflict: kudzu conflicts kernel < 2.6.13 >--> Processing Dependency: python = 2.4.1 for package: smart >--> Restarting Dependency Resolution with new changes. >--> Populating transaction set with selected packages. Please wait. >--> Running transaction check >Error: Missing Dependency: python = 2.4.1 is needed by package smart >Error: Unable to satisfy dependencies >Error: Package initscripts needs kernel < 2.6.12, this is not available. >Error: Package kudzu needs kernel < 2.6.13, this is not available. >Error: Package smart needs python = 2.4.1, this is not available. >------------------------------------------------------------------------ > >Is there any way to fix that manually? Is it possible to access to >Rawhide via SmartPM? If so, what channel would that be? > > No idea about smartpm. The steps to do this using yum is here : http://fedoraproject.org/wiki/Docs/Drafts/TestingGuide -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From igorm5 at vip.hr Wed Dec 28 17:51:12 2005 From: igorm5 at vip.hr (Igor Jagec) Date: Wed, 28 Dec 2005 18:51:12 +0100 Subject: Can't upgrade to Rawhide In-Reply-To: <1135770512.7725.3.camel@stonewall.northforty.net> References: <43B26CBB.5080105@vip.hr> <1135770512.7725.3.camel@stonewall.northforty.net> Message-ID: <43B2D090.10704@vip.hr> Michael D. Wise wrote: > You need to remove all installed kernel versions less that 2.6.14. That > should fix you initscripts and kudzu conflicts. Damm, I forgot to remove the older kernel packages :) Of course it works now! :) Thanks to all of you guys! > I don't know what that > smart package is but it looks like you need to upgrade that as well > before you can upgrade python. That's not a problem, I was going to remove smart packages in the first place, but thanks again to all of you guys! :) And the nice thing is that FC5 kernel doesn't hang on boot as it was before. The only problem is that I can't install nvidia drivers, but I suppose that's an nvidia, or Xorg issue. Cheers! -- Igor Jagec From lists at wilsonet.com Wed Dec 28 21:46:26 2005 From: lists at wilsonet.com (Jarod Wilson) Date: Wed, 28 Dec 2005 13:46:26 -0800 Subject: Can't upgrade to Rawhide In-Reply-To: <43B2AF5D.9030408@redhat.com> References: <43B26CBB.5080105@vip.hr> <43B2AF5D.9030408@redhat.com> Message-ID: <200512281346.30358.lists@wilsonet.com> On Wednesday 28 December 2005 07:29, Rahul Sundaram wrote: > Igor Jagec wrote: > >I'm trying to upgrade to Rawhide from fully updated FC4 on my test > >partition for quite some time, but I never manage to succeed it. Yum > >constantly give me some errors, such as: > >Is there any way to fix that manually? What everyone else said. > >Is it possible to access to > >Rawhide via SmartPM? If so, what channel would that be? > > No idea about smartpm. The steps to do this using yum is here : > http://fedoraproject.org/wiki/Docs/Drafts/TestingGuide Yes, smart can also use yum repodata, just set up new channels of that type, point it to the same urls you'll find in /etc/yum.repos.d/*-devel.repo. http://labix.org/smart/faq#head-23a262be2555f1b386b7f8ca158010a49dd07ad3 -- Jarod Wilson jarod at wilsonet.com -------------- 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 redhat.com Wed Dec 28 21:58:51 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 29 Dec 2005 03:28:51 +0530 Subject: Can't upgrade to Rawhide In-Reply-To: <200512281346.30358.lists@wilsonet.com> References: <43B26CBB.5080105@vip.hr> <43B2AF5D.9030408@redhat.com> <200512281346.30358.lists@wilsonet.com> Message-ID: <43B30A9B.6030503@redhat.com> Hi >Yes, smart can also use yum repodata, just set up new channels of that type, >point it to the same urls you'll find in /etc/yum.repos.d/*-devel.repo. > >http://labix.org/smart/faq#head-23a262be2555f1b386b7f8ca158010a49dd07ad3 > > > Smartpm can use yum metadata but its not just a frontend and its dependency resolves works very differently. Most notably it attempts to downgrade packages on occasions to resolve dependencies automatically which isnt what RPM is optimally designed or tested to do. Whether its desirable or if its a improvement is debatable. Yum obviously is getting better integrated with Anaconda, system-config-packages and so on. Of course now that Smartpm is under review for Fedora Extras repository, you have the choice easily. -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From jarod at wilsonet.com Wed Dec 28 22:41:24 2005 From: jarod at wilsonet.com (Jarod Wilson) Date: Wed, 28 Dec 2005 14:41:24 -0800 Subject: Can't upgrade to Rawhide In-Reply-To: <43B30A9B.6030503@redhat.com> References: <43B26CBB.5080105@vip.hr> <200512281346.30358.lists@wilsonet.com> <43B30A9B.6030503@redhat.com> Message-ID: <200512281441.27243.jarod@wilsonet.com> On Wednesday 28 December 2005 13:58, Rahul Sundaram wrote: > >Yes, smart can also use yum repodata, just set up new channels of that > > type, point it to the same urls you'll find in > > /etc/yum.repos.d/*-devel.repo. > > > >http://labix.org/smart/faq#head-23a262be2555f1b386b7f8ca158010a49dd07ad3 > > Smartpm can use yum metadata but its not just a frontend and its > dependency resolves works very differently. Most notably it attempts to > downgrade packages on occasions to resolve dependencies automatically > which isnt what RPM is optimally designed or tested to do. Whether its > desirable or if its a improvement is debatable. Yum obviously is getting > better integrated with Anaconda, system-config-packages and so on. Of > course now that Smartpm is under review for Fedora Extras repository, > you have the choice easily. Personally, I used to be a die-hard apt user, but I've been using mostly yum of late (it has improved by leaps and bounds in the past year or so). And yeah, yum is getting better and better integration w/the rest of Fedora. Smart does have some intriguing "features" though. :) -- Jarod Wilson jarod at wilsonet.com -------------- 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 redhat.com Wed Dec 28 22:48:15 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 29 Dec 2005 04:18:15 +0530 Subject: Can't upgrade to Rawhide In-Reply-To: <200512281441.27243.jarod@wilsonet.com> References: <43B26CBB.5080105@vip.hr> <200512281346.30358.lists@wilsonet.com> <43B30A9B.6030503@redhat.com> <200512281441.27243.jarod@wilsonet.com> Message-ID: <43B3162F.1040206@redhat.com> Hi > >Smart does have some intriguing "features" though. :) > > What do people find interesting about it? . Remember to separate the core features from the ones the GUI presents which can be added to things like system-config-packages or yumex. -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From igorm5 at vip.hr Thu Dec 29 01:47:42 2005 From: igorm5 at vip.hr (Igor Jagec) Date: Thu, 29 Dec 2005 02:47:42 +0100 Subject: OOo 2.0 with Bluecurve icon set Message-ID: <43B3403E.3080703@vip.hr> Is there any chance of seeing the Bluecurve icon set in the new OOo 2.0 in upcoming FC5? I don't like the default icon set very much, and the Bluecurve icon set on OOo 1.1.x branch looked great. It would be very nice to follow the tradition since RHEL5 will be based on FC5, AFAIK ;) Cheers! -- Igor Jagec From igorm5 at vip.hr Thu Dec 29 01:33:33 2005 From: igorm5 at vip.hr (Igor Jagec) Date: Thu, 29 Dec 2005 02:33:33 +0100 Subject: Can't upgrade to Rawhide In-Reply-To: <43B30A9B.6030503@redhat.com> References: <43B26CBB.5080105@vip.hr> <43B2AF5D.9030408@redhat.com> <200512281346.30358.lists@wilsonet.com> <43B30A9B.6030503@redhat.com> Message-ID: <43B33CED.7010303@vip.hr> Rahul Sundaram wrote: >> http://labix.org/smart/faq#head-23a262be2555f1b386b7f8ca158010a49dd07ad3 I know for that, but SmartPM just hanged when I was tryed to upgrade the system into Rawhide. Here's my channel: ---------------------------------------------------------------------- # Name: Development # URL: http://ayo.freshrpms.net/ [fc-dev] name = Development baseurl = http://ayo.freshrpms.net/fedora/linux/development/i386/core/ type = rpm-md ---------------------------------------------------------------------- > Smartpm can use yum metadata but its not just a frontend and its > dependency resolves works very differently. Most notably it attempts to > downgrade packages on occasions to resolve dependencies automatically > which isnt what RPM is optimally designed or tested to do. I didn't know for that, thanks. > Whether its > desirable or if its a improvement is debatable. Yum obviously is getting > better integrated with Anaconda, system-config-packages and so on. I read that Yum is the new dependency resolver for Anaconda, and system-config-packages as well. I like Yum better because it provides some features I've never seen on Apt or Smart (package repackaging and installing packages locally - 'yum localinstall'). But it is slower than Apt and Smart, for now :-/ > Of > course now that Smartpm is under review for Fedora Extras repository, > you have the choice easily. Well, I'm not some SmartPM fan or something, I was just playing with it. Seems nice tool. Or it isn't as it looks like? Cheers! -- Igor Jagec From igorm5 at vip.hr Thu Dec 29 01:38:11 2005 From: igorm5 at vip.hr (Igor Jagec) Date: Thu, 29 Dec 2005 02:38:11 +0100 Subject: Can't upgrade to Rawhide In-Reply-To: <43B3162F.1040206@redhat.com> References: <43B26CBB.5080105@vip.hr> <200512281346.30358.lists@wilsonet.com> <43B30A9B.6030503@redhat.com> <200512281441.27243.jarod@wilsonet.com> <43B3162F.1040206@redhat.com> Message-ID: <43B33E03.6070204@vip.hr> Rahul Sundaram wrote: > What do people find interesting about it? . Remember to separate the > core features from the ones the GUI presents which can be added to > things like system-config-packages or yumex. I never use GUI tools myself. I only wanted to see if Smart really resolves dependencies better than the other tools. The only problem I saw till now is that it upgrades kernel-devel package instead of install it. Of course, it lack of some features like package repackaging or installing packages locally but I suppose that is expected in such early phase of development. I hope that Yum will be faster and faster from version to version... Cheers! -- Igor Jagec From sundaram at redhat.com Thu Dec 29 02:14:03 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Thu, 29 Dec 2005 07:44:03 +0530 Subject: Can't upgrade to Rawhide In-Reply-To: <43B33CED.7010303@vip.hr> References: <43B26CBB.5080105@vip.hr> <43B2AF5D.9030408@redhat.com> <200512281346.30358.lists@wilsonet.com> <43B30A9B.6030503@redhat.com> <43B33CED.7010303@vip.hr> Message-ID: <43B3466B.20808@redhat.com> Hi >I like Yum better because it provides >some features I've never seen on Apt or Smart (package repackaging and >installing packages locally - 'yum localinstall'). But it is slower than >Apt and Smart, for now :-/ > Yum has constantly got improvements in speed over almost every release. Learn to use yum -C if you want it to run from cache on occasions. Also the version in the Fedora development tree has a timeout value set to 1800 seconds by default to avoid refreshing the cache on subsequent operations which makes a pretty major difference. -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From igorm5 at vip.hr Thu Dec 29 02:21:45 2005 From: igorm5 at vip.hr (Igor Jagec) Date: Thu, 29 Dec 2005 03:21:45 +0100 Subject: Can't upgrade to Rawhide In-Reply-To: <43B3466B.20808@redhat.com> References: <43B26CBB.5080105@vip.hr> <43B2AF5D.9030408@redhat.com> <200512281346.30358.lists@wilsonet.com> <43B30A9B.6030503@redhat.com> <43B33CED.7010303@vip.hr> <43B3466B.20808@redhat.com> Message-ID: <43B34839.60001@vip.hr> Rahul Sundaram wrote: >> I like Yum better because it provides >> some features I've never seen on Apt or Smart (package repackaging and >> installing packages locally - 'yum localinstall'). But it is slower than >> Apt and Smart, for now :-/ > Yum has constantly got improvements in speed over almost every release. > Learn to use yum -C if you want it to run from cache on > occasions. Also the version in the Fedora development tree has a timeout > value set to 1800 seconds by default to avoid refreshing the cache on > subsequent operations which makes a pretty major difference. On FC4 too. I got it recently. I think it is 2.4.1 version (I'm currently on Rawhide). Here's my yum.conf: [main] cachedir=/var/cache/yum debuglevel=2 logfile=/var/log/yum.log pkgpolicy=newest distroverpkg=redhat-release tolerant=1 exactarch=1 retries=1 timeout=10 obsoletes=1 gpgcheck=0 exclude=transcode* tsflags=repackage metadata_expire=1800 -- Igor Jagec From jarod at wilsonet.com Thu Dec 29 04:09:06 2005 From: jarod at wilsonet.com (Jarod Wilson) Date: Wed, 28 Dec 2005 20:09:06 -0800 Subject: Can't upgrade to Rawhide In-Reply-To: <43B3162F.1040206@redhat.com> References: <43B26CBB.5080105@vip.hr> <200512281441.27243.jarod@wilsonet.com> <43B3162F.1040206@redhat.com> Message-ID: <200512282009.07032.jarod@wilsonet.com> On Wednesday 28 December 2005 14:48, Rahul Sundaram wrote: > >Smart does have some intriguing "features" though. :) > > What do people find interesting about it? . Remember to separate the > core features from the ones the GUI presents which can be added to > things like system-config-packages or yumex. Primarily the downgrading packages to resolve deps and support for multiple repository metadata formats intrigue me. Though why I'd need to install anything from a red carpet or apt repo that doesn't also provide yum metadata, I dunno. Oh, and on the GUI front... I actually think smart's GUI sucks (at least, the last time I looked at it, but its been a few revs). -- Jarod Wilson jarod at wilsonet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jarod at wilsonet.com Thu Dec 29 04:12:09 2005 From: jarod at wilsonet.com (Jarod Wilson) Date: Wed, 28 Dec 2005 20:12:09 -0800 Subject: Can't upgrade to Rawhide In-Reply-To: <43B33E03.6070204@vip.hr> References: <43B26CBB.5080105@vip.hr> <43B3162F.1040206@redhat.com> <43B33E03.6070204@vip.hr> Message-ID: <200512282012.09480.jarod@wilsonet.com> On Wednesday 28 December 2005 17:38, Igor Jagec wrote: > Rahul Sundaram wrote: > > What do people find interesting about it? . Remember to separate the > > core features from the ones the GUI presents which can be added to > > things like system-config-packages or yumex. > > I never use GUI tools myself. I only wanted to see if Smart really > resolves dependencies better than the other tools. The only problem I > saw till now is that it upgrades kernel-devel package instead of install > it. Of course, it lack of some features like package repackaging or > installing packages locally but I suppose that is expected in such early > phase of development. I hope that Yum will be faster and faster from > version to version... Er, smart has supported installing packages off your local system since its inception. Or did I misunderstand what you were saying there? No, from another msg of yours in the thread, looks like you're thinking smart has no equivalent to yum's localinstall. Just "smart install foo-1.1-1.i386.rpm" like it says in the smart FAQ. :) -- Jarod Wilson jarod at wilsonet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From admin at ramshacklestudios.com Thu Dec 29 04:40:39 2005 From: admin at ramshacklestudios.com (Peter Gordon) Date: Wed, 28 Dec 2005 20:40:39 -0800 Subject: OOo 2.0 with Bluecurve icon set In-Reply-To: <43B3403E.3080703@vip.hr> References: <43B3403E.3080703@vip.hr> Message-ID: <1135831239.5730.2.camel@tuxhugger> On Thu, 2005-12-29 at 02:47 +0100, Igor Jagec wrote: > Is there any chance of seeing the Bluecurve icon set in the new OOo 2.0 > in upcoming FC5? I don't like the default icon set very much, and the > Bluecurve icon set on OOo 1.1.x branch looked great. It would be very > nice to follow the tradition since RHEL5 will be based on FC5, AFAIK ;) I'd love this, too. It would give a tighter "look-and-feel" integration of OpenOffice.org into the rest of my GNOME desktop. :-) -- Peter Gordon (codergeek42) GnuPG Public Key: 0xDA3634D7 -------------- 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 m.f.h at web.de Thu Dec 29 06:42:12 2005 From: m.f.h at web.de (Marcus Hartig) Date: Thu, 29 Dec 2005 07:42:12 +0100 Subject: Can't upgrade to Rawhide In-Reply-To: <43B2D090.10704@vip.hr> References: <43B26CBB.5080105@vip.hr> <1135770512.7725.3.camel@stonewall.northforty.net> <43B2D090.10704@vip.hr> Message-ID: <43B38544.5020906@web.de> Igor Jagec wrote: > And the nice thing is that FC5 kernel doesn't hang on boot as it was > before. The only problem is that I can't install nvidia drivers, but I > suppose that's an nvidia, or Xorg issue. Install the nvidia driver with: sh drivername --x-module-path=/usr/lib/xorg/modules Marcus From gianluca.cecchi at gmail.com Thu Dec 29 06:45:03 2005 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Thu, 29 Dec 2005 07:45:03 +0100 Subject: kudzu illegal instruction at startup Message-ID: <561c252c0512282245r30eb4fadk@mail.gmail.com> hello, when kudzu starts it gives Checking for hardware changes/etc/rc.d/init.d/kudzu: line 23: 3937 Illegal instruction /sbin/kudzu $KUDZU_ARGS [FAILED] in "start" function there is /sbin/kudzu $KUDZU_ARGS -z || /sbin/kudzu $KUDZU_ARGS instead of typical /usr/sbin/kudzu $KUDZU_ARGS -t 30 if [ "$RETVAL" -eq 5 ]; then echo -n $"Hardware configuration timed out." echo -n $"Run '/usr/sbin/kudzu' from the command line to re-detect." initlog -n kudzu -s $"Hardware configuration timed out." initlog -n kudzu -s $"Run '/usr/sbin/kudzu' from the command line to re-detect." fi Any reason for that? Gianluca -------------- next part -------------- An HTML attachment was scrubbed... URL: From davej at redhat.com Thu Dec 29 06:48:07 2005 From: davej at redhat.com (Dave Jones) Date: Thu, 29 Dec 2005 01:48:07 -0500 Subject: kudzu illegal instruction at startup In-Reply-To: <561c252c0512282245r30eb4fadk@mail.gmail.com> References: <561c252c0512282245r30eb4fadk@mail.gmail.com> Message-ID: <20051229064807.GA3652@redhat.com> On Thu, Dec 29, 2005 at 07:45:03AM +0100, Gianluca Cecchi wrote: > hello, > when kudzu starts it gives > > Checking for hardware changes/etc/rc.d/init.d/kudzu: line 23: 3937 Illegal > instruction /sbin/kudzu $KUDZU_ARGS > [FAILED] What CPU are you running on ? Did you move disks between two different machines by any chance ? Do you get the same thing when you run it by hand from the command line ? If so, running it under gdb (with the kudzu-debuginfo package installed) should give you a backtrace of where the problem occured. Dave From gianluca.cecchi at gmail.com Thu Dec 29 06:52:56 2005 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Thu, 29 Dec 2005 07:52:56 +0100 Subject: fsck after crash not active in fc5 dev? In-Reply-To: <561c252c0512240657q5ef59948m@mail.gmail.com> References: <561c252c0512240657q5ef59948m@mail.gmail.com> Message-ID: <561c252c0512282252k7033adco@mail.gmail.com> Any answers/comments on this? I was not able to find any entry in bugzilla... Can you confirm it was not intentional? Gianluca 2005/12/24, Gianluca Cecchi : > > Hello, > I noticed after a crash (due to loss of electricity) that file systems was > not asked to be fscked > after reboot. The file /.autofsck is created at boot, as before, but > comparing rh el 4 with fc5 it seemes that inside rc.sysinit the piece > below is missing, so that > the system does not prompt if one wants to force fsck and one has to > manually create /forcefsck and reboot in this case > (or probably is there a boot flag to tell to force fsck? I don't know > this). > > if [ "$PROMPT" != "no" ]; then > if [ "$AUTOFSCK_DEF_CHECK" = "yes" ]; then > if /sbin/getkey -c $AUTOFSCK_TIMEOUT -m $"Press N > within %d seconds to not force file system integrity check..." n ; then > AUTOFSCK_OPT= > fi > else > if /sbin/getkey -c $AUTOFSCK_TIMEOUT -m $"Press Y > within %d seconds to force file system integrity check..." y ; then > AUTOFSCK_OPT=-f > fi > fi > echo > else > # PROMPT not allowed > if [ "$AUTOFSCK_DEF_CHECK" = "yes" ]; then > echo $"Forcing file system integrity check due to > default setting" > else > echo $"Not forcing file system integrity check due > to default setting" > fi > fi > I'm testing fedora right now and don't know previous versions, so this > could also be standard policy for fedora. Sorry in this case. > Is this ok, due to devel os or did it disappear uncorrectly? > I would like to have this chance also for devel/test systems. > Just my opinion. > Thanks for reading. > Gianluca > -------------- next part -------------- An HTML attachment was scrubbed... URL: From buildsys at redhat.com Thu Dec 29 08:04:50 2005 From: buildsys at redhat.com (Build System) Date: Thu, 29 Dec 2005 03:04:50 -0500 Subject: rawhide report: 20051229 changes Message-ID: <200512290804.jBT84otF006544@porkchop.devel.redhat.com> Updated Packages: GFS-kernel-2.6.14.1-20051219.162641.FC5.6 ----------------------------------------- * Wed Dec 28 2005 Jesse Keating - rebuilt cman-kernel-2.6.14.1-20051219.162641.FC5.5 ------------------------------------------ * Wed Dec 28 2005 Jesse Keating - rebuilt dlm-kernel-2.6.14.1-20051219.162641.FC5.5 ----------------------------------------- * Wed Dec 28 2005 Jesse Keating - rebuilt gnbd-kernel-2.6.14.0-20051108.134753.FC5.12.28 ---------------------------------------------- * Wed Dec 28 2005 Jesse Keating - rebuilt kernel-2.6.14-1.1796_FC5 ------------------------ * Wed Dec 28 2005 Dave Jones - 2.6.15-rc7-git2 - Reduce stack usage in block layer. - Limit number of serial ports registered at boot time. - Fix spinlock corruption in cfq with ub. selinux-policy-2.1.6-18 ----------------------- * Wed Dec 28 2005 Dan Walsh 2.1.6-18 - Fix /dev/ub[a-z] file context Broken deps for i386 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 Broken deps for ia64 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) Broken deps for s390 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 systemtap - 0.5.2-2.s390 requires kernel >= 0:2.6.9-11 systemtap - 0.5.2-2.s390 requires kernel-devel Broken deps for s390x ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) systemtap - 0.5.2-2.s390x requires kernel >= 0:2.6.9-11 systemtap - 0.5.2-2.s390x requires kernel-devel Broken deps for x86_64 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) From jfrieben at freesurf.fr Thu Dec 29 08:05:49 2005 From: jfrieben at freesurf.fr (Joachim Frieben) Date: Thu, 29 Dec 2005 09:05:49 +0100 (CET) Subject: OOo 2.0 with Bluecurve icon set In-Reply-To: <43B3403E.3080703@vip.hr> References: <43B3403E.3080703@vip.hr> Message-ID: <62834.194.94.224.254.1135843549.squirrel@jose.freesurf.fr> This is a definitely worthwile suggestion! The Bluecurve icon set is really missing here. It would be even better, if the core GNOME apps also got a consistent icon theming. There are quite a few places where the really ugly stock GNOME icons and the Bluecurve ones are still mixed. > Is there any chance of seeing the Bluecurve icon set in the new OOo 2.0 > in upcoming FC5? I don't like the default icon set very much, and the > Bluecurve icon set on OOo 1.1.x branch looked great. It would be very > nice to follow the tradition since RHEL5 will be based on FC5, AFAIK ;) From nicu_fedora at nicubunu.ro Thu Dec 29 09:22:56 2005 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Thu, 29 Dec 2005 11:22:56 +0200 Subject: OOo 2.0 with Bluecurve icon set In-Reply-To: <43B3403E.3080703@vip.hr> References: <43B3403E.3080703@vip.hr> Message-ID: <43B3AAF0.5080408@nicubunu.ro> Igor Jagec wrote: > Is there any chance of seeing the Bluecurve icon set in the new OOo 2.0 > in upcoming FC5? I don't like the default icon set very much, and the > Bluecurve icon set on OOo 1.1.x branch looked great. It would be very > nice to follow the tradition since RHEL5 will be based on FC5, AFAIK ;) From my observation, the time remaining until FC5 makes this an unrealistic expectation, maybe FC6 can be a reasonable target. OOo had a big change in the way it work with icons from 1.1.x to 2.x, so this is a big work. Also, consider the Bluecurve icon set in OOo 1.1.x was completed halfway (only the most used icons), with the rest of the icons being GNOME Industrial, this makes me doubt even FC6 as a realistic target unless this is identified as a major goal and serious efforts are allocated to it. The good news is that someone inside Red Hat is working on freeing the icon sources, which will allow external contributors to participate in development (but this is not easy, do not expect something in the near future). -- nicu my hats collection: http://fedora.nicubunu.ro/hats/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From gianluca.cecchi at gmail.com Thu Dec 29 09:31:41 2005 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Thu, 29 Dec 2005 10:31:41 +0100 Subject: kudzu illegal instruction at startup Message-ID: <561c252c0512290131q47dc535ay@mail.gmail.com> >What CPU are you running on ? Did you move disks between two >different machines by any chance ? The machine is a dual athlon Mp. I previously installed fc5 devel and further updates on a vmware workstation virtual machine on this host. Then I dumped all files on a preformatted partition of this host. Then with chroot, grub setup, dev files creation, mkinitrd re-run and other conf file modifications I am able to boot natively in fc5. I expected kudzu to help doing this reconfiguration.... >Do you get the same thing when you run it by hand from the command line ? >If so, running it under gdb (with the kudzu-debuginfo package installed) >should give you a backtrace of where the problem occured. Yes it gives the same error. I'm going to install kudzu-debuginfo and let you know... Thankls, Gianluca -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpeters at mac.com Thu Dec 29 09:42:24 2005 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 29 Dec 2005 01:42:24 -0800 Subject: texdoc and TEXDOCVIEW_pdf Message-ID: <1135849346.4685.64.camel@locolhost.localdomain> texdoc is a shell script from tetex. By default for viewing pdf files that are part of the tex documentation, it wants to use xpdf. xpdf is no longer installed by default, so a user is required to either install it - or set the TEXDOCVIEW_pdf environmental variable themselves to something else (like evince) - otherwise they get an xpdf command not found error. This would be nice to resolve for FC5 if it can be properly done. Would it be better to install something in /etc/profile.d/ that sets TEXDOCVIEW_pdf to something like gnome-open? That should still allow the a user to put in their own TEXDOCVIEW_pdf if they wanted to, but would use their default pdf reader if they didn't set anything themselves. This may need to be done for more than just the TEXDOCVIEW_pdf environmental variable, but I think something needs to be done to avoid texdoc complaining about a lack of xpdf when a perfectly good PDF viewer (such as evince or Acrobat) is installed. It also seems like it should use the users preferred application for viewing PDF files. Only potential issue I can think of would be KDE users etc. who don't have gnome-open installed. A standard wrapper that uses the appropriate viewer for the desktop being used would be better, if such a thing exists (since tetex is not a gnome app). From pmatilai at laiskiainen.org Thu Dec 29 11:17:33 2005 From: pmatilai at laiskiainen.org (Panu Matilainen) Date: Thu, 29 Dec 2005 03:17:33 -0800 (PST) Subject: Can't upgrade to Rawhide In-Reply-To: <43B33CED.7010303@vip.hr> References: <43B26CBB.5080105@vip.hr> <43B2AF5D.9030408@redhat.com> <200512281346.30358.lists@wilsonet.com> <43B30A9B.6030503@redhat.com> <43B33CED.7010303@vip.hr> Message-ID: On Thu, 29 Dec 2005, Igor Jagec wrote: > > I read that Yum is the new dependency resolver for Anaconda, and > system-config-packages as well. I like Yum better because it provides > some features I've never seen on Apt or Smart (package repackaging and > installing packages locally - 'yum localinstall'). But it is slower than > Apt and Smart, for now :-/ Apt does actually support both repackaging and local package installations and I'd suppose smart does too (but haven't checked) - Panu - From jnovy at redhat.com Thu Dec 29 11:48:45 2005 From: jnovy at redhat.com (Jindrich Novy) Date: Thu, 29 Dec 2005 12:48:45 +0100 Subject: texdoc and TEXDOCVIEW_pdf In-Reply-To: <1135849346.4685.64.camel@locolhost.localdomain> References: <1135849346.4685.64.camel@locolhost.localdomain> Message-ID: <1135856926.25950.7.camel@localhost.localdomain> On Thu, 2005-12-29 at 01:42 -0800, Michael A. Peters wrote: > texdoc is a shell script from tetex. > > By default for viewing pdf files that are part of the tex documentation, > it wants to use xpdf. > > xpdf is no longer installed by default, so a user is required to either > install it - or set the TEXDOCVIEW_pdf environmental variable themselves > to something else (like evince) - otherwise they get an xpdf command not > found error. > > This would be nice to resolve for FC5 if it can be properly done. texdoc indeed needs updating to more recent application bindings suitable for FC5, the xpdf is just one example, but texdoc also uses gv to handle PostScript files what's also not too good. Could you file a bz for it? Package descriptions need updating as well, so I'll fix it all at once. Jindrich -- Jindrich Novy , http://people.redhat.com/jnovy/ (o_ _o) //\ The worst evil in the world is refusal to think. //\ V_/_ _\_V From gianluca.cecchi at gmail.com Thu Dec 29 12:30:30 2005 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Thu, 29 Dec 2005 13:30:30 +0100 Subject: kudzu illegal instruction at startup In-Reply-To: <561c252c0512282245r30eb4fadk@mail.gmail.com> References: <561c252c0512282245r30eb4fadk@mail.gmail.com> Message-ID: <561c252c0512290430l2eaacc02w@mail.gmail.com> It is strange to reproduce, as kudzu is a shell script. And right this boot time it gave no error. Analyzing commands, it seems that the offending command is kudzu -z || kudzu Tipically tou have sometimes the illegal option error, sometimes not, and it happens with the second kudzu in the command So I tried a two times sequence with: [root at fedora ~]# kudzu -z ||gdb kudzu GNU gdb Red Hat Linux (6.3.0.0-1.94rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /sbin/kudzu Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0x3b4000 Program exited normally. (gdb) quit [root at fedora ~]# kudzu -z ||gdb kudzu GNU gdb Red Hat Linux (6.3.0.0-1.94rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/libthread_db.so.1". (gdb) run Starting program: /sbin/kudzu Reading symbols from shared object read from target memory...done. Loaded system supplied DSO at 0x745000 Program received signal SIGILL, Illegal instruction. 0x0805ee2f in run_vm86 () at lrmi.c:733 733 asm volatile ( (gdb) (gdb) quit The program is running. Exit anyway? (y or n) y I don't know if other answers in last error could be more useful... HIH, Gianluca 2005/12/29, Gianluca Cecchi : > > hello, > when kudzu starts it gives > > Checking for hardware changes/etc/rc.d/init.d/kudzu: line 23: 3937 > Illegal instruction /sbin/kudzu $KUDZU_ARGS > [FAILED] > in "start" function there is > > /sbin/kudzu $KUDZU_ARGS -z || /sbin/kudzu $KUDZU_ARGS > > instead of typical > > /usr/sbin/kudzu $KUDZU_ARGS -t 30 > > if [ "$RETVAL" -eq 5 ]; then > echo -n $"Hardware configuration timed out." > echo -n $"Run '/usr/sbin/kudzu' from the command line to > re-detect." > initlog -n kudzu -s $"Hardware configuration timed out." > initlog -n kudzu -s $"Run '/usr/sbin/kudzu' from the command > line to re-detect." > fi > > Any reason for that? > Gianluca > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From maxer1 at xmission.com Thu Dec 29 13:57:06 2005 From: maxer1 at xmission.com (RaXeT) Date: Thu, 29 Dec 2005 06:57:06 -0700 Subject: kudzu illegal instruction at startup Message-ID: <43B3EB32.9000008@xmission.com> On Thu, Dec 29, 2005 at 07:45:03AM +0100, Gianluca Cecchi wrote: > hello, > when kudzu starts it gives > > Checking for hardware changes/etc/rc.d/init.d/kudzu: line 23: 3937 Illegal > instruction /sbin/kudzu $KUDZU_ARGS > [FAILED] You may want to look at the bug I posted on this: Bugzilla - 176490 From brilong at cisco.com Thu Dec 29 14:21:28 2005 From: brilong at cisco.com (Brian Long) Date: Thu, 29 Dec 2005 09:21:28 -0500 Subject: FC5 and Yum Plugins Message-ID: <1135866089.4433.35.camel@brilong-lnx> I was wondering what folks thought about including a few yum plugins out-of-the-box on FC5. I've got a MythTV setup a home running FC4, but I add ATRPMS and FreshRPMs repos to be able to easily install MythTV and satisfy its requirements. I believe other users of Fedora are in the same boat; we have to use third-party repos but we don't want them ever overriding Fedora RPMs. I've manually installed the "protectbase" and "fastestmirror" plugins from the yum-utils tarball (they are not included in the yum-utils RPM or subpackages yet). I would think installing protectbase by default on FC5 and protecting all Fedora official repos would be excellent. I added protect=1 to fedora.repo, fedora-updates.repo and fedora-extras.repo after making sure the plugin was enabled and yum.conf had "plugins=1". This allows me to run the following command without AtRPMS changing any RPMs that are included in [base], [updates] or [extras]: yum --enablerepo=atrpms --enablerepo=freshrpms update Normally, I have atrpms and freshrpms disabled; base, updates and extras are enabled. Without protectbase installed, atrpms wants to provide updates to xorg-X11 and various other packages which I don't want. However, it provides a bunch of MythTV updates I do want (about 30 RPMs or so). Since I don't want to iterate manually through all the MythTV updates, I find protectbase a good compromise. I would think it would be in the best interest of the Fedora team to install protectbase by default, enable it and protect Fedora repos. If power users want to disable it, it's very easy. Am I off-base in this request? :) /Brian/ -- Brian Long | | | IT Data Center Systems | .|||. .|||. Cisco Linux Developer | ..:|||||||:...:|||||||:.. Phone: (919) 392-7363 | C i s c o S y s t e m s From gianluca.cecchi at gmail.com Thu Dec 29 14:41:15 2005 From: gianluca.cecchi at gmail.com (Gianluca Cecchi) Date: Thu, 29 Dec 2005 15:41:15 +0100 Subject: kudzu illegal instruction at startup Message-ID: <561c252c0512290641k5dfd272ew@mail.gmail.com> >You may want to look at the bug I posted on this: > >Bugzilla - 176490 Strange enough, yesterday before posting I searched through bugzilla with kudzu as the key, but fewer results appeared than today, and nothing in particular for the seg fault thing. Thanks. I updated this bug number with my debug information. Gianluca -------------- next part -------------- An HTML attachment was scrubbed... URL: From m.f.h at web.de Thu Dec 29 15:33:12 2005 From: m.f.h at web.de (Marcus Hartig) Date: Thu, 29 Dec 2005 16:33:12 +0100 Subject: texdoc and TEXDOCVIEW_pdf In-Reply-To: <1135849346.4685.64.camel@locolhost.localdomain> References: <1135849346.4685.64.camel@locolhost.localdomain> Message-ID: <43B401B8.8080506@web.de> Michael A. Peters wrote: > xpdf is no longer installed by default, so a user is required to either > install it - or set the TEXDOCVIEW_pdf environmental variable themselves > to something else (like evince) - otherwise they get an xpdf command not > found error. Yes. And using perhaps evince per default is good. pdf's are everywhere in daily use and an important must... Marcus From wrrhdev at riede.org Thu Dec 29 16:19:52 2005 From: wrrhdev at riede.org (Willem Riede) Date: Thu, 29 Dec 2005 11:19:52 -0500 Subject: FC5 and Yum Plugins In-Reply-To: <1135866089.4433.35.camel@brilong-lnx> (from brilong@cisco.com on Thu Dec 29 09:21:28 2005) References: <1135866089.4433.35.camel@brilong-lnx> Message-ID: <1135873192l.19816l.1l@athena.riede.org> On 12/29/2005 09:21:28 AM, Brian Long wrote: > > I've manually installed the "protectbase" and "fastestmirror" plugins > from the yum-utils tarball (they are not included in the yum-utils RPM > or subpackages yet). > > I would think installing protectbase by default on FC5 and protecting > all Fedora official repos would be excellent. I added protect=1 to > fedora.repo, fedora-updates.repo and fedora-extras.repo after making > sure the plugin was enabled and yum.conf had "plugins=1". This allows > me to run the following command without AtRPMS changing any RPMs that > are included in [base], [updates] or [extras]: > > yum --enablerepo=atrpms --enablerepo=freshrpms update > > Normally, I have atrpms and freshrpms disabled; base, updates and extras > are enabled. Without protectbase installed, atrpms wants to provide > updates to xorg-X11 and various other packages which I don't want. > However, it provides a bunch of MythTV updates I do want (about 30 RPMs > or so). Since I don't want to iterate manually through all the MythTV > updates, I find protectbase a good compromise. > > I would think it would be in the best interest of the Fedora team to > install protectbase by default, enable it and protect Fedora repos. If > power users want to disable it, it's very easy. > > Am I off-base in this request? :) I don't think so - I would like to see this too. By the way, I made a variant on "fastestmirror" that I called "bestmirror" that also checks which mirrors have the most recent updates (as indicated by the age of their metadata). That way you're certain to get the most recent version of a package (though there was some concern expressed about the load created on the mirrors by all that polling...) Regards, Willem Riede. From jspaleta at gmail.com Thu Dec 29 16:28:52 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 29 Dec 2005 11:28:52 -0500 Subject: FC5 and Yum Plugins In-Reply-To: <1135866089.4433.35.camel@brilong-lnx> References: <1135866089.4433.35.camel@brilong-lnx> Message-ID: <604aa7910512290828n760cd03en3b5c7bd87c5fa55a@mail.gmail.com> On 12/29/05, Brian Long wrote: > I would think it would be in the best interest of the Fedora team to > install protectbase by default, enable it and protect Fedora repos. If > power users want to disable it, it's very easy. > > Am I off-base in this request? :) Have you spoken with the atrpms and freshrpms maintainers? Do you have their agreement that turning this on is in the best interest of their users? I don't see the point in turning this on by default if the 3rd party repository maintainers are not interested in see it on by default. 3rd party repos could very easily nullify whatever protection it provides by introducing scriptlet action in one or all of their packages if they felt protectbase was getting in the way of the correct operation of their repository. And if that happens the protectbase becomes worthless. you MUST get the maintainers of the popular 3rd party repos to agree that turning protectbase on by default is something they will respoect in their packaging and not try to disable via package scriptlet action. -jef From brilong at cisco.com Thu Dec 29 16:50:44 2005 From: brilong at cisco.com (Brian Long) Date: Thu, 29 Dec 2005 11:50:44 -0500 Subject: FC5 and Yum Plugins In-Reply-To: <604aa7910512290828n760cd03en3b5c7bd87c5fa55a@mail.gmail.com> References: <1135866089.4433.35.camel@brilong-lnx> <604aa7910512290828n760cd03en3b5c7bd87c5fa55a@mail.gmail.com> Message-ID: <1135875044.4433.52.camel@brilong-lnx> On Thu, 2005-12-29 at 11:28 -0500, Jeff Spaleta wrote: > On 12/29/05, Brian Long wrote: > > I would think it would be in the best interest of the Fedora team to > > install protectbase by default, enable it and protect Fedora repos. If > > power users want to disable it, it's very easy. > > > > Am I off-base in this request? :) > > Have you spoken with the atrpms and freshrpms maintainers? Do you have > their agreement that turning this on is in the best interest of their > users? Nope. I don't know that it's up to me or the Fedora project to contact each third-party repo maintainer when Fedora implements a change. I'm asking Fedora to consider a change. If Fedora decides to implement that change for the "protection" of their users and repos, the third party repos would shoot themselves in the foot if they started scripting around the protection! IMHO, they would lose credibility. I believe there are 2 types of 3rd party repo users: 1) Fedora user who needs 3rd party repos for certain apps but never wants that repo to override base Fedora RPMs 2) Fedora user who wants 3rd party repos for everything and wants them to override base Fedora RPMs #1 is fairly safe, #2 is flying by the seat of your pants. I'm suggesting we configure the protectbase yum plugin such that #1 is default. If a user wants to be #2, they need to comment out the "protect=1" line in the fedora*.repo files. AtRPMs and other third party repos should not automate the removal of protect=1; they would need to inform users what to do to switch from scenario #1 and #2. Maybe this would complicate matters too much, but I'd like to see Fedora be configured as #1 out-of-the-box. /Brian/ -- Brian Long | | | IT Data Center Systems | .|||. .|||. Cisco Linux Developer | ..:|||||||:...:|||||||:.. Phone: (919) 392-7363 | C i s c o S y s t e m s From naheemzaffar at gmail.com Thu Dec 29 17:11:29 2005 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Thu, 29 Dec 2005 17:11:29 +0000 Subject: OOo 2.0 with Bluecurve icon set In-Reply-To: <43B3AAF0.5080408@nicubunu.ro> References: <43B3403E.3080703@vip.hr> <43B3AAF0.5080408@nicubunu.ro> Message-ID: <3adc77210512290911g7284bcdcn8dc5672028ac26fb@mail.gmail.com> If the iconset is not complete, maybe it would be a good idea for redhat to donate them as a contribution to the tango-project? There many eyes may be able to complete the set, and allow it for use across many desktops? (having a look at the Tango-project, I think some icons there are fugly. Hopefully as a bi-product, those would be replaced by the better ones in the bluecurve set... All icons there seem to be head-on, with the light source directly above, so that may clash...) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jspaleta at gmail.com Thu Dec 29 17:11:30 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 29 Dec 2005 12:11:30 -0500 Subject: FC5 and Yum Plugins In-Reply-To: <1135875044.4433.52.camel@brilong-lnx> References: <1135866089.4433.35.camel@brilong-lnx> <604aa7910512290828n760cd03en3b5c7bd87c5fa55a@mail.gmail.com> <1135875044.4433.52.camel@brilong-lnx> Message-ID: <604aa7910512290911o7b4bd611kac6d3cecb1e83591@mail.gmail.com> On 12/29/05, Brian Long wrote: > Nope. I don't know that it's up to me or the Fedora project to contact > each third-party repo maintainer when Fedora implements a change. I'm > asking Fedora to consider a change. And I'm telling you...since you used atrpms and freshrpms as the motivating example.. you should go out and contact those maintainers about how they feel about YOUR idea to make this default. Shoving a new default into Core tool configs that is meant as a constraint on interaction with 3rd party repos is ill-advised without the input from the maintainers of those repos. For you to suggest that the 3rd party maintainer's opinion doesn't hold significant weight shows an absolute lack of understanding of the history of this project's relationship with 3rd party maintainers. >If Fedora decides to implement that > change for the "protection" of their users and repos, the third party > repos would shoot themselves in the foot if they started scripting > around the protection! IMHO, they would lose credibility. Considering that you are having problems with repos that already feel they have a good reason to overwrite Core packaging decisions... i think you making too many damned assumptions about what 3rd party maintainers think. I don't care how many users think protectbase on by default is a good idea. If 90% of the users are like you and trying to protect themselves against atrpm overwrites.. you better make damn sure that atrpms is going to respect protectbase's default status. We aren't solving any problems by turning this on by default unless the 3rd party maintainers that most users have problems with agree to respect the config. As an mythtv atrpms package user, i would think you would want to make sure Axel was behind this idea. In fact I say any user of mythtv packages from atrpms loses credibility in this discussion if they do not seek out Axel's opinion on that matter. The last thing you want as a user of any atrpms packages is MORE hostibility between this project and atrpms... because its just going to end up making it more difficult for you as the user. -jef From wrrhdev at riede.org Thu Dec 29 17:13:33 2005 From: wrrhdev at riede.org (Willem Riede) Date: Thu, 29 Dec 2005 12:13:33 -0500 Subject: Should udev have created /dev/modem? Message-ID: <1135876413l.3688l.0l@athena.riede.org> I plugged in my U.S.Robotics 56000 Voice USB Modem. When I booted fc5-devel, "/dev/ttyACM0" was created for it. But no symbolic link to /dev/modem. Should that have happened? If that is up to me to configure, what is the right way to do so on fc5? Thanks, Willem Riede. From fedora at leemhuis.info Thu Dec 29 17:18:00 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 29 Dec 2005 18:18:00 +0100 Subject: FC5 and Yum Plugins In-Reply-To: <1135875044.4433.52.camel@brilong-lnx> References: <1135866089.4433.35.camel@brilong-lnx> <604aa7910512290828n760cd03en3b5c7bd87c5fa55a@mail.gmail.com> <1135875044.4433.52.camel@brilong-lnx> Message-ID: <1135876680.2665.13.camel@localhost.localdomain> Am Donnerstag, den 29.12.2005, 11:50 -0500 schrieb Brian Long: > On Thu, 2005-12-29 at 11:28 -0500, Jeff Spaleta wrote: > > On 12/29/05, Brian Long wrote: > > > I would think it would be in the best interest of the Fedora team to > > > install protectbase by default, enable it and protect Fedora repos. If > > > power users want to disable it, it's very easy. > > > Am I off-base in this request? :) > > Have you spoken with the atrpms and freshrpms maintainers? Do you have > > their agreement that turning this on is in the best interest of their > > users? > > Nope. I don't know that it's up to me or the Fedora project to contact > each third-party repo maintainer when Fedora implements a change. I'm > asking Fedora to consider a change. If Fedora decides to implement that > change for the "protection" of their users and repos, the third party > repos would shoot themselves in the foot if they started scripting > around the protection! IMHO, they would lose credibility. They don't override base Fedora RPMs just for fun, they afaik do it because some of the their packages need fixes and/or enhancements that are not in the base Fedora RPMs (correct me if I'm wrong here). So if you protect the Core packages some packages in the 3rd-Party might not work (or not perfectly). So it probably creates more problems for the user and the 3rd party repo maintainer than it solves. > I believe there are 2 types of 3rd party repo users: > > 1) Fedora user who needs 3rd party repos for certain apps but never > wants that repo to override base Fedora RPMs Then use a 3rd party repo that does not override Fedora Core or Extras RPMS. Yes, such a repo exists, but no, I still has no mythtv -- nobody stepped up to package it there. Any volunteers? CU thl -- Thorsten Leemhuis From naheemzaffar at gmail.com Thu Dec 29 17:27:55 2005 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Thu, 29 Dec 2005 17:27:55 +0000 Subject: FC5 and Yum Plugins In-Reply-To: <1135876680.2665.13.camel@localhost.localdomain> References: <1135866089.4433.35.camel@brilong-lnx> <604aa7910512290828n760cd03en3b5c7bd87c5fa55a@mail.gmail.com> <1135875044.4433.52.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> Message-ID: <3adc77210512290927j539ffe8ep9472a2e7f5a54a1a@mail.gmail.com> I think it is a good idea to protect the base repositories, but it is not clear-cut. Secondly third parties should try to parallel-install any package instead of replacing the core-supplied one. (or work with Fedora in such a way that instead of replacing a package all they need to do is provide a plugin...). I can see this is probably not always possible, and am certain 3rd parties would already have thought of this... so I may just be wasting space here. What if 3rd parties start shipping their repo files with the protection enabled aswell? would that be of benefit, or would it lose the benefits of such a system? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jspaleta at gmail.com Thu Dec 29 17:30:16 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 29 Dec 2005 12:30:16 -0500 Subject: FC5 and Yum Plugins In-Reply-To: <1135876680.2665.13.camel@localhost.localdomain> References: <1135866089.4433.35.camel@brilong-lnx> <604aa7910512290828n760cd03en3b5c7bd87c5fa55a@mail.gmail.com> <1135875044.4433.52.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> Message-ID: <604aa7910512290930k7893583bpca523bd5da2dca56@mail.gmail.com> On 12/29/05, Thorsten Leemhuis wrote: > Then use a 3rd party repo that does not override Fedora Core or Extras > RPMS. Yes, such a repo exists, but no, I still has no mythtv -- nobody > stepped up to package it there. Any volunteers? I don't think this is a technically correct statement anymore to say that Livna doesn't override Core and Extras. For example, audacity exists in both Extras and Livna, with different compile options because of mp3 support issues, i believe. And i think the maintainer of kdemultimedia-extras is working on a similar livna/extras duplication arrangement. This of course also makes the issue of protectbase on by default more difficult, because if applied to Extras it would concievable hold-back packages with mp3 support in livna that duplicate extras. And I really can't imagine many users wanting that situation by default -jef From jamatos at fc.up.pt Thu Dec 29 17:35:01 2005 From: jamatos at fc.up.pt (Jose' Matos) Date: Thu, 29 Dec 2005 17:35:01 +0000 Subject: FC5 and Yum Plugins In-Reply-To: <604aa7910512290930k7893583bpca523bd5da2dca56@mail.gmail.com> References: <1135866089.4433.35.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> <604aa7910512290930k7893583bpca523bd5da2dca56@mail.gmail.com> Message-ID: <200512291735.01201.jamatos@fc.up.pt> On Thursday 29 December 2005 17:30, Jeff Spaleta wrote: > And i think the maintainer > of kdemultimedia-extras is working on a similar livna/extras > duplication arrangement. Jeff I don't think that this bit is correct, the package for lvn will be kdemultimedia-nonfree (in the mp3 sense) AFAIK. The purpose of this decision was precisely to avoid such scenario. :-) -- Jos? Ab?lio From jspaleta at gmail.com Thu Dec 29 17:37:32 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 29 Dec 2005 12:37:32 -0500 Subject: FC5 and Yum Plugins In-Reply-To: <200512291735.01201.jamatos@fc.up.pt> References: <1135866089.4433.35.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> <604aa7910512290930k7893583bpca523bd5da2dca56@mail.gmail.com> <200512291735.01201.jamatos@fc.up.pt> Message-ID: <604aa7910512290937i6b6b859fu6c41355e5da1596c@mail.gmail.com> On 12/29/05, Jose' Matos wrote: > Jeff I don't think that this bit is correct, the package for lvn will be > kdemultimedia-nonfree (in the mp3 sense) AFAIK. The purpose of this decision > was precisely to avoid such scenario. :-) the scenario already exists with audacity.... -jef From fedora at leemhuis.info Thu Dec 29 17:46:06 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Thu, 29 Dec 2005 18:46:06 +0100 Subject: FC5 and Yum Plugins In-Reply-To: <604aa7910512290930k7893583bpca523bd5da2dca56@mail.gmail.com> References: <1135866089.4433.35.camel@brilong-lnx> <604aa7910512290828n760cd03en3b5c7bd87c5fa55a@mail.gmail.com> <1135875044.4433.52.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> <604aa7910512290930k7893583bpca523bd5da2dca56@mail.gmail.com> Message-ID: <1135878367.2665.31.camel@localhost.localdomain> Am Donnerstag, den 29.12.2005, 12:30 -0500 schrieb Jeff Spaleta: > On 12/29/05, Thorsten Leemhuis wrote: > > Then use a 3rd party repo that does not override Fedora Core or Extras > > RPMS. Yes, such a repo exists, but no, I still has no mythtv -- nobody > > stepped up to package it there. Any volunteers? > > I don't think this is a technically correct statement anymore to say > that Livna doesn't override Core and Extras. For example, audacity > exists in both Extras and Livna, with different compile options > because of mp3 support issues, i believe. /me checks and jeff seems to be right > And i think the maintainer > of kdemultimedia-extras is working on a similar livna/extras > duplication arrangement. Yeah. It's a pity that both lack a plugin-system for stuff like mp3-support. But if the maintainer is the same in livna and extras I don't see a big problem -- yes, it's a problem, but has anybody a better solution? One idea: Create a sub-repo in livna with all the packages that replace/update/conflict with other Core or Extras packages. > This of course also makes the issue of protectbase on by default more > difficult, because if applied to Extras it would concievable hold-back > packages with mp3 support in livna that duplicate extras. And I > really can't imagine many users wanting that situation by default Probably. -- Thorsten Leemhuis From jspaleta at gmail.com Thu Dec 29 17:57:30 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 29 Dec 2005 12:57:30 -0500 Subject: FC5 and Yum Plugins In-Reply-To: <1135878367.2665.31.camel@localhost.localdomain> References: <1135866089.4433.35.camel@brilong-lnx> <604aa7910512290828n760cd03en3b5c7bd87c5fa55a@mail.gmail.com> <1135875044.4433.52.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> <604aa7910512290930k7893583bpca523bd5da2dca56@mail.gmail.com> <1135878367.2665.31.camel@localhost.localdomain> Message-ID: <604aa7910512290957l3141464epa4ba16b801a4c97a@mail.gmail.com> On 12/29/05, Thorsten Leemhuis wrote: > But if the maintainer is the same in livna and extras I don't see a big > problem -- yes, it's a problem, but has anybody a better solution? Its only a problem in the context of this "protectbase by default" discussion. -jef From brilong at cisco.com Thu Dec 29 18:25:05 2005 From: brilong at cisco.com (Brian Long) Date: Thu, 29 Dec 2005 13:25:05 -0500 Subject: FC5 and Yum Plugins In-Reply-To: <604aa7910512290911o7b4bd611kac6d3cecb1e83591@mail.gmail.com> References: <1135866089.4433.35.camel@brilong-lnx> <604aa7910512290828n760cd03en3b5c7bd87c5fa55a@mail.gmail.com> <1135875044.4433.52.camel@brilong-lnx> <604aa7910512290911o7b4bd611kac6d3cecb1e83591@mail.gmail.com> Message-ID: <1135880705.4433.76.camel@brilong-lnx> On Thu, 2005-12-29 at 12:11 -0500, Jeff Spaleta wrote: > On 12/29/05, Brian Long wrote: > > Nope. I don't know that it's up to me or the Fedora project to contact > > each third-party repo maintainer when Fedora implements a change. I'm > > asking Fedora to consider a change. > > And I'm telling you...since you used atrpms and freshrpms as the > motivating example.. you should go out and contact those maintainers > about how they feel about YOUR idea to make this default. Shoving a > new default into Core tool configs that is meant as a constraint on > interaction with 3rd party repos is ill-advised without the input from > the maintainers of those repos. For you to suggest that the 3rd party > maintainer's opinion doesn't hold significant weight shows an absolute > lack of understanding of the history of this project's relationship > with 3rd party maintainers. There is no need to attack people personally in this discussion. I figured this discussion would be healthy, but I think you're crossing the line. I never said 3rd party maintainer's opinion didn't carry weight; I said it's not the job of the Fedora development team to get buy-in from every 3rd party maintainer before making a change. There is a big difference between the two. > >If Fedora decides to implement that > > change for the "protection" of their users and repos, the third party > > repos would shoot themselves in the foot if they started scripting > > around the protection! IMHO, they would lose credibility. > > Considering that you are having problems with repos that already feel > they have a good reason to overwrite Core packaging decisions... i > think you making too many damned assumptions about what 3rd party > maintainers think. I don't care how many users think protectbase on > by default is a good idea. If 90% of the users are like you and trying > to protect themselves against atrpm overwrites.. you better make damn > sure that atrpms is going to respect protectbase's default status. We > aren't solving any problems by turning this on by default unless the > 3rd party maintainers that most users have problems with agree to > respect the config. As an mythtv atrpms package user, i would think > you would want to make sure Axel was behind this idea. In fact I say > any user of mythtv packages from atrpms loses credibility in this > discussion if they do not seek out Axel's opinion on that matter. The > last thing you want as a user of any atrpms packages is MORE > hostibility between this project and atrpms... because its just going > to end up making it more difficult for you as the user. Why are you cussing? Does it make you feel you get your point across? I'm not trying to make assumptions about the 3rd party maintainers. I'm relying on the folks familiar with Fedora development to flush out my idea, riddle it with holes, flush it down the toilet or accept it. It's just a discussion topic, nothing meant to piss people off or start a flame war. Jeez! :-) /Brian/ -- Brian Long | | | IT Data Center Systems | .|||. .|||. Cisco Linux Developer | ..:|||||||:...:|||||||:.. Phone: (919) 392-7363 | C i s c o S y s t e m s From pquiring at hotmail.com Thu Dec 29 18:31:42 2005 From: pquiring at hotmail.com (Peter Quiring) Date: Thu, 29 Dec 2005 13:31:42 -0500 Subject: vmware player direct3d Message-ID: <43B42B8E.7020202@hotmail.com> I've recently downloaded vmware player from vmware.com and it works with Fedora Core 5 test1. Using some sample images from their website (Browser-Appliance) I managed to edit the vmx file and make it boot from a cdrom and installed Win2000Pro (had to change the scsi type from lsilogic to buslogic). It works! 100% free! I no longer have to boot to Windoze for "some" apps. Then I learned that they have Direct3D support as well (many claim that even WC3 works) but it doesn't work for me with FC5. vmware says it can't create a 3d object and disables 3d support. I've downloaded BillardGL from sourceforge compiled and run it without any problems so I know my GL system is intact. The only issue I've noticed is that GL apps don't seem to restore my resolution after exiting (that's another unrelated issue). But vmware 1.0.1 doesn't see that GL is available. I've also posted this at vmware's discussion forums. Of course Wine is a better option, and once working again with X11R7 I will give it a try again, but vmware has it's advantages too. Any ideas? Peter From arjan at fenrus.demon.nl Thu Dec 29 18:46:57 2005 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Thu, 29 Dec 2005 19:46:57 +0100 Subject: vmware player direct3d In-Reply-To: <43B42B8E.7020202@hotmail.com> References: <43B42B8E.7020202@hotmail.com> Message-ID: <1135882017.2935.71.camel@laptopd505.fenrus.org> On Thu, 2005-12-29 at 13:31 -0500, Peter Quiring wrote: > Any ideas? I think this question is a bit offtopic for fedora-devel-list; it's 100% about vmware player and 0% about the development of fedora. I suggest that you post your question on a vmware forum/list or if you really want to ask it for fedora, on fedora-list. From nicolas.mailhot at laposte.net Thu Dec 29 18:47:26 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 29 Dec 2005 19:47:26 +0100 (CET) Subject: FC5 and Yum Plugins In-Reply-To: <1135876680.2665.13.camel@localhost.localdomain> References: <1135866089.4433.35.camel@brilong-lnx> <604aa7910512290828n760cd03en3b5c7bd87c5fa55a@mail.gmail.com> <1135875044.4433.52.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> Message-ID: <43396.82.231.92.235.1135882046.squirrel@rousalka.dyndns.org> On Jeu 29 d?cembre 2005 18:18, Thorsten Leemhuis wrote: > Am Donnerstag, den 29.12.2005, 11:50 -0500 schrieb Brian Long: >> >> I believe there are 2 types of 3rd party repo users: >> >> 1) Fedora user who needs 3rd party repos for certain apps but never >> wants that repo to override base Fedora RPMs > > Then use a 3rd party repo that does not override Fedora Core or Extras > RPMS. Yes, such a repo exists, but no, I still has no mythtv -- nobody > stepped up to package it there. Any volunteers? I suspect this will happen real soon after ivtv is merged in upstream kernel and appears in Raw Hide (ivtv is currently being merged with v4l, which will be then merged upstream) There's no real point in packaging mythtv cleanly when the driver most users need is not available easily without all sorts of fugly kernel patching. I know I will donate personnaly packaging time if necessary to make it happen. But there's no real point now, packaging mythtv is one thing, messing with the kernel is another. I have a lot of repect for the people that try to maintain kernel modules in FE or livna but little wish to join them. Regards, -- Nicolas Mailhot From nicolas.mailhot at laposte.net Thu Dec 29 18:53:02 2005 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Thu, 29 Dec 2005 19:53:02 +0100 (CET) Subject: FC5 and Yum Plugins In-Reply-To: <1135876680.2665.13.camel@localhost.localdomain> References: <1135866089.4433.35.camel@brilong-lnx> <604aa7910512290828n760cd03en3b5c7bd87c5fa55a@mail.gmail.com> <1135875044.4433.52.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> Message-ID: <52903.82.231.92.235.1135882382.squirrel@rousalka.dyndns.org> On Jeu 29 d?cembre 2005 18:18, Thorsten Leemhuis wrote: > They don't override base Fedora RPMs just for fun, they afaik do it > because some of the their packages need fixes and/or enhancements that > are not in the base Fedora RPMs (correct me if I'm wrong here). In the atrpm case, they can do it and the result is more feature complete. That all the added features were absolutely necessary is something else entirely (meaning I'm not sure Axel tries very hard not to fork FC packages - in fact since he supports lots of ancient Red Hat distributions, it's probably easier for him to fork everything rather than try to make the best decision for FC4/Raw Hide alone) From mpeters at mac.com Thu Dec 29 19:07:53 2005 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 29 Dec 2005 11:07:53 -0800 Subject: FC5 and Yum Plugins In-Reply-To: <1135875044.4433.52.camel@brilong-lnx> References: <1135866089.4433.35.camel@brilong-lnx> <604aa7910512290828n760cd03en3b5c7bd87c5fa55a@mail.gmail.com> <1135875044.4433.52.camel@brilong-lnx> Message-ID: <1135883273.4685.98.camel@locolhost.localdomain> On Thu, 2005-12-29 at 11:50 -0500, Brian Long wrote: > > Nope. I don't know that it's up to me or the Fedora project to contact > each third-party repo maintainer when Fedora implements a change. I'm > asking Fedora to consider a change. I agree. If it messes up a third party repository, the third party repository can instruct users to disable it if using the repository. That might clue some users in that they really don't want to messing with third party due to the implications (changing core packages) while allowing those who do to alter the settings. Replacing core rpm's with third party rpm's is not recommended imho. In fact - I would even suggest protecting FC Extras (though perhaps not by default). That being said - I probably would disable the plugin (or make an exception for a few packages) since I rebuild sox for mp3 support on my boxes - but I think the default should be that users have to take a step to disable protection, not take a step to enable protection. From mpeters at mac.com Thu Dec 29 19:12:38 2005 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 29 Dec 2005 11:12:38 -0800 Subject: FC5 and Yum Plugins In-Reply-To: <604aa7910512290957l3141464epa4ba16b801a4c97a@mail.gmail.com> References: <1135866089.4433.35.camel@brilong-lnx> <604aa7910512290828n760cd03en3b5c7bd87c5fa55a@mail.gmail.com> <1135875044.4433.52.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> <604aa7910512290930k7893583bpca523bd5da2dca56@mail.gmail.com> <1135878367.2665.31.camel@localhost.localdomain> <604aa7910512290957l3141464epa4ba16b801a4c97a@mail.gmail.com> Message-ID: <1135883558.4685.101.camel@locolhost.localdomain> On Thu, 2005-12-29 at 12:57 -0500, Jeff Spaleta wrote: > On 12/29/05, Thorsten Leemhuis wrote: > > But if the maintainer is the same in livna and extras I don't see a big > > problem -- yes, it's a problem, but has anybody a better solution? > > Its only a problem in the context of this "protectbase by default" discussion. None of those are "base" packages, but you won't find me complaining if livna took the Fedora sox spec file and added libmad-devel and lame-devel to the BuildRequires ... which would be a "base" package being replaced ... From mpeters at mac.com Thu Dec 29 19:15:04 2005 From: mpeters at mac.com (Michael A. Peters) Date: Thu, 29 Dec 2005 11:15:04 -0800 Subject: FC5 and Yum Plugins In-Reply-To: <604aa7910512290937i6b6b859fu6c41355e5da1596c@mail.gmail.com> References: <1135866089.4433.35.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> <604aa7910512290930k7893583bpca523bd5da2dca56@mail.gmail.com> <200512291735.01201.jamatos@fc.up.pt> <604aa7910512290937i6b6b859fu6c41355e5da1596c@mail.gmail.com> Message-ID: <1135883704.4685.104.camel@locolhost.localdomain> On Thu, 2005-12-29 at 12:37 -0500, Jeff Spaleta wrote: > On 12/29/05, Jose' Matos wrote: > > Jeff I don't think that this bit is correct, the package for lvn will be > > kdemultimedia-nonfree (in the mp3 sense) AFAIK. The purpose of this decision > > was precisely to avoid such scenario. :-) > > the scenario already exists with audacity.... Hopefully Marlin (or something like it) will mature enough to replace audacity - so that installing a gstreamer plugin is all that is required. From Axel.Thimm at ATrpms.net Thu Dec 29 19:39:58 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 29 Dec 2005 20:39:58 +0100 Subject: FC5 and Yum Plugins In-Reply-To: <1135876680.2665.13.camel@localhost.localdomain> References: <1135866089.4433.35.camel@brilong-lnx> <604aa7910512290828n760cd03en3b5c7bd87c5fa55a@mail.gmail.com> <1135875044.4433.52.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> Message-ID: <20051229193958.GC4833@neu.nirvana> On Thu, Dec 29, 2005 at 06:18:00PM +0100, Thorsten Leemhuis wrote: > Am Donnerstag, den 29.12.2005, 11:50 -0500 schrieb Brian Long: > > On Thu, 2005-12-29 at 11:28 -0500, Jeff Spaleta wrote: > > > On 12/29/05, Brian Long wrote: > > > > I would think it would be in the best interest of the Fedora team to > > > > install protectbase by default, enable it and protect Fedora repos. If > > > > power users want to disable it, it's very easy. > > > > Am I off-base in this request? :) > > > Have you spoken with the atrpms and freshrpms maintainers? Do you have > > > their agreement that turning this on is in the best interest of their > > > users? > > > > Nope. I don't know that it's up to me or the Fedora project to contact > > each third-party repo maintainer when Fedora implements a change. I'm > > asking Fedora to consider a change. If Fedora decides to implement that > > change for the "protection" of their users and repos, the third party > > repos would shoot themselves in the foot if they started scripting > > around the protection! IMHO, they would lose credibility. > > They don't override base Fedora RPMs just for fun, they afaik do it > because some of the their packages need fixes and/or enhancements that > are not in the base Fedora RPMs (correct me if I'm wrong here). > > So if you protect the Core packages some packages in the 3rd-Party might > not work (or not perfectly). So it probably creates more problems for > the user and the 3rd party repo maintainer than it solves. Exactly. Which is why any repo, be it atrpms or something else, that does see a need to replace package foo in core, and thus has overlapping package sets with core will not like this idiom. I have already been hit by bug reports that stem from improper use of priorities/weights and scores. Such filtering creates a lot more issues and debugging problems than it solves. > > I believe there are 2 types of 3rd party repo users: > > > > 1) Fedora user who needs 3rd party repos for certain apps but never > > wants that repo to override base Fedora RPMs > > Then use a 3rd party repo that does not override Fedora Core or Extras > RPMS. Yes, such a repo exists, but no, I still has no mythtv -- nobody > stepped up to package it there. Any volunteers? What would your conclusion be if in the middle of porting these 30+ packages from ATrpms you find out that you *need* to replace packages from core? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Dec 29 19:44:39 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 29 Dec 2005 20:44:39 +0100 Subject: FC5 and Yum Plugins In-Reply-To: <43396.82.231.92.235.1135882046.squirrel@rousalka.dyndns.org> References: <1135866089.4433.35.camel@brilong-lnx> <604aa7910512290828n760cd03en3b5c7bd87c5fa55a@mail.gmail.com> <1135875044.4433.52.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> <43396.82.231.92.235.1135882046.squirrel@rousalka.dyndns.org> Message-ID: <20051229194439.GD4833@neu.nirvana> On Thu, Dec 29, 2005 at 07:47:26PM +0100, Nicolas Mailhot wrote: > > On Jeu 29 d?cembre 2005 18:18, Thorsten Leemhuis wrote: > > Am Donnerstag, den 29.12.2005, 11:50 -0500 schrieb Brian Long: > >> > >> I believe there are 2 types of 3rd party repo users: > >> > >> 1) Fedora user who needs 3rd party repos for certain apps but never > >> wants that repo to override base Fedora RPMs > > > > Then use a 3rd party repo that does not override Fedora Core or Extras > > RPMS. Yes, such a repo exists, but no, I still has no mythtv -- nobody > > stepped up to package it there. Any volunteers? > > I suspect this will happen real soon after ivtv is merged in upstream > kernel and appears in Raw Hide (ivtv is currently being merged with v4l, > which will be then merged upstream) > > There's no real point in packaging mythtv cleanly when the driver most > users need is not available easily without all sorts of fugly kernel > patching. You assume that mythtv users are mostly using PVR x50 cards? I think most are doing DVB based setups (or ATSC) instead, which is in modern FC kernels. The existence or not of a driver is not very much relevant for mythtv/freevo or friends. In fact the driver <-> application model is quite orthogonal (and that is good). > I know I will donate personnaly packaging time if necessary to make it > happen. But there's no real point now, packaging mythtv is one thing, > messing with the kernel is another. I have a lot of repect for the people > that try to maintain kernel modules in FE or livna but little wish to join > them. There are rpms for ivtv since two or three years at ATrpms. BTW ATrpms even hosts the ivtv project ... -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Thu Dec 29 19:46:50 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 29 Dec 2005 14:46:50 -0500 Subject: FC5 and Yum Plugins In-Reply-To: <1135883558.4685.101.camel@locolhost.localdomain> References: <1135866089.4433.35.camel@brilong-lnx> <604aa7910512290828n760cd03en3b5c7bd87c5fa55a@mail.gmail.com> <1135875044.4433.52.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> <604aa7910512290930k7893583bpca523bd5da2dca56@mail.gmail.com> <1135878367.2665.31.camel@localhost.localdomain> <604aa7910512290957l3141464epa4ba16b801a4c97a@mail.gmail.com> <1135883558.4685.101.camel@locolhost.localdomain> Message-ID: <604aa7910512291146n79893284q5a234c67464f654a@mail.gmail.com> On 12/29/05, Michael A. Peters wrote: > None of those are "base" packages, but you won't find me complaining if > livna took the Fedora sox spec file and added libmad-devel and > lame-devel to the BuildRequires ... which would be a "base" package > being replaced ... "protectbase" doesnt mean "base" if you look back at the original post.. he added protectbase functionality to extras as well. And if you wanted to turn protectbase on by default you'd have put Extras in the protection pool... there is nothing stopping something moving into Core out of Extras as part of a new dependancy for a Core update. -jef From ivazquez at ivazquez.net Thu Dec 29 19:47:15 2005 From: ivazquez at ivazquez.net (Ignacio Vazquez-Abrams) Date: Thu, 29 Dec 2005 14:47:15 -0500 Subject: Should udev have created /dev/modem? In-Reply-To: <1135876413l.3688l.0l@athena.riede.org> References: <1135876413l.3688l.0l@athena.riede.org> Message-ID: <1135885635.15039.1.camel@ignacio.lan> On Thu, 2005-12-29 at 12:13 -0500, Willem Riede wrote: > I plugged in my U.S.Robotics 56000 Voice USB Modem. When I booted fc5-devel, > "/dev/ttyACM0" was created for it. But no symbolic link to /dev/modem. > > Should that have happened? If that is up to me to configure, what is the right > way to do so on fc5? http://www.reactivated.net/udevrules.php -- Ignacio Vazquez-Abrams http://fedora.ivazquez.net/ gpg --keyserver hkp://subkeys.pgp.net --recv-key 38028b72 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part URL: From jspaleta at gmail.com Thu Dec 29 19:49:21 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 29 Dec 2005 14:49:21 -0500 Subject: FC5 and Yum Plugins In-Reply-To: <20051229193958.GC4833@neu.nirvana> References: <1135866089.4433.35.camel@brilong-lnx> <604aa7910512290828n760cd03en3b5c7bd87c5fa55a@mail.gmail.com> <1135875044.4433.52.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> <20051229193958.GC4833@neu.nirvana> Message-ID: <604aa7910512291149x75ca6dc9g22d6b7149943f2d5@mail.gmail.com> On 12/29/05, Axel Thimm wrote: > Exactly. Which is why any repo, be it atrpms or something else, that > does see a need to replace package foo in core, and thus has > overlapping package sets with core will not like this idiom. I have > already been hit by bug reports that stem from improper use of > priorities/weights and scores. Such filtering creates a lot more > issues and debugging problems than it solves. let's be clear.... if protectbase plugin was turned on by default would atrpm leave it enabled on client system or would you attempt to disable the plugin via package scriptlet action? -jef From Axel.Thimm at ATrpms.net Thu Dec 29 20:07:44 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 29 Dec 2005 21:07:44 +0100 Subject: FC5 and Yum Plugins In-Reply-To: <604aa7910512291149x75ca6dc9g22d6b7149943f2d5@mail.gmail.com> References: <1135866089.4433.35.camel@brilong-lnx> <604aa7910512290828n760cd03en3b5c7bd87c5fa55a@mail.gmail.com> <1135875044.4433.52.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> <20051229193958.GC4833@neu.nirvana> <604aa7910512291149x75ca6dc9g22d6b7149943f2d5@mail.gmail.com> Message-ID: <20051229200744.GE4833@neu.nirvana> On Thu, Dec 29, 2005 at 02:49:21PM -0500, Jeff Spaleta wrote: > On 12/29/05, Axel Thimm wrote: > > Exactly. Which is why any repo, be it atrpms or something else, that > > does see a need to replace package foo in core, and thus has > > overlapping package sets with core will not like this idiom. I have > > already been hit by bug reports that stem from improper use of > > priorities/weights and scores. Such filtering creates a lot more > > issues and debugging problems than it solves. > > let's be clear.... if protectbase plugin was turned on by default > would atrpm leave it enabled on client system or would you attempt to > disable the plugin via package scriptlet action? That sounds too sneaky. While such a setup would generate grand headaches to most 3rd party repos (if not all, if there any big one w/o replacements?) as you and Thorsten already outlined (so it's better not to get as far as to have this as a default), I'd rather find a different solution to this problem, and I believe the other 3rd party repo maintainers would feel the same. It's not a repository war to invent new ways of dumping the other side (I hope). Certainly this kind of yum setup would not be a supported setup by the repos needing these replacements, so either way you look at it, this idiom cannot be welcomed by any such repo. In fact it would make yum itself as a depsolver unusable for these repos. So to answer your question directly: ATrpms would try to avoid such a setup by all (fair) means, and not having ATrpms at all on your client system would be a preferable setup to one with broken dependencies. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Thu Dec 29 20:29:15 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 29 Dec 2005 21:29:15 +0100 Subject: FC5 and Yum Plugins In-Reply-To: <1135878367.2665.31.camel@localhost.localdomain> References: <1135866089.4433.35.camel@brilong-lnx> <604aa7910512290828n760cd03en3b5c7bd87c5fa55a@mail.gmail.com> <1135875044.4433.52.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> <604aa7910512290930k7893583bpca523bd5da2dca56@mail.gmail.com> <1135878367.2665.31.camel@localhost.localdomain> Message-ID: <20051229202915.GF4833@neu.nirvana> On Thu, Dec 29, 2005 at 06:46:06PM +0100, Thorsten Leemhuis wrote: > Am Donnerstag, den 29.12.2005, 12:30 -0500 schrieb Jeff Spaleta: > > On 12/29/05, Thorsten Leemhuis wrote: > > > Then use a 3rd party repo that does not override Fedora Core or Extras > > > RPMS. Yes, such a repo exists, but no, I still has no mythtv -- nobody > > > stepped up to package it there. Any volunteers? > > > > I don't think this is a technically correct statement anymore to say > > that Livna doesn't override Core and Extras. For example, audacity > > exists in both Extras and Livna, with different compile options > > because of mp3 support issues, i believe. > > /me checks and jeff seems to be right > > > And i think the maintainer of kdemultimedia-extras is working on a > > similar livna/extras duplication arrangement. > > Yeah. It's a pity that both lack a plugin-system for stuff like > mp3-support. There are other examples as well. For giving a historical one: At some time in the past RHL something was building samba w/o any ldap support as this setup wasn't being supported by RH. Still the samba users started harassing 3rd party repo maintainers to provide them with such augmented functionality and some did so. This is just one example of a stand-alone replacement ("stand-alone" as contrasted to replacements made due to other packages requiring them). I'm not advocating that this is good. Neither whether kdemultimedia-extras or audacity/mp3 overlap is good, or not. Just pointing out the neccessity for some users. I'd also prefer having plugin-architectures to everything so nothing needs to be overlapping anymore. But other than the kernel there is hardly something in a modular plugin architecture for packaging purposes. > But if the maintainer is the same in livna and extras I don't see a big > problem -- yes, it's a problem, but has anybody a better solution? One > idea: Create a sub-repo in livna with all the packages that > replace/update/conflict with other Core or Extras packages. That idea was there from the begining of the Fedora XXX repo definitions, it was called Fedora Alternatives [1]. But no repo ever accepted this idea, so it was dropped. It even disappeared from the terminology web pages. This (dead-born) concept showed that it would had been indeed helpful to discuss this with the community and the third party repo maintainers before defining and publishing it, like it is being done now for the yum plugin suggestion. If you suggest "alternatives" to livna maintainership it will still not have good chances of being accepted as it generates overhead w/o any noticable benefits to both users and maintainers (other than getting out of the discussion ;). Note that any package depending on a package in an "alternatives" repo needs to be demoted to this repo, too. So you may end up with quite a lot of packages in this at the beginning-assumed-to-be-small side-repo. [1] Fedora Alternatives suggested hosting at redhat.com, but the term alternatives was mostly used w/o this hosting context. > > This of course also makes the issue of protectbase on by default more > > difficult, because if applied to Extras it would concievable hold-back > > packages with mp3 support in livna that duplicate extras. And I > > really can't imagine many users wanting that situation by default > > Probably. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jspaleta at gmail.com Thu Dec 29 20:28:34 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Thu, 29 Dec 2005 15:28:34 -0500 Subject: FC5 and Yum Plugins In-Reply-To: <20051229200744.GE4833@neu.nirvana> References: <1135866089.4433.35.camel@brilong-lnx> <604aa7910512290828n760cd03en3b5c7bd87c5fa55a@mail.gmail.com> <1135875044.4433.52.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> <20051229193958.GC4833@neu.nirvana> <604aa7910512291149x75ca6dc9g22d6b7149943f2d5@mail.gmail.com> <20051229200744.GE4833@neu.nirvana> Message-ID: <604aa7910512291228q322ed93awd3df7442aca9c438@mail.gmail.com> On 12/29/05, Axel Thimm wrote: > That sounds too sneaky. While such a setup would generate grand > headaches to most 3rd party repos (if not all, if there any big one > w/o replacements?) as you and Thorsten already outlined (so it's > better not to get as far as to have this as a default), I'd rather > find a different solution to this problem, and I believe the other 3rd > party repo maintainers would feel the same. It's not a repository war > to invent new ways of dumping the other side (I hope). > > Certainly this kind of yum setup would not be a supported setup by the > repos needing these replacements, so either way you look at it, this > idiom cannot be welcomed by any such repo. In fact it would make yum > itself as a depsolver unusable for these repos. > > So to answer your question directly: ATrpms would try to avoid such a > setup by all (fair) means, and not having ATrpms at all on your client > system would be a preferable setup to one with broken dependencies. I think protectbase by default is a particularly bad idea for a number of reasons. But if i understand the original poster correctly, the problem he wants solved is a way to easily update packages in a way that recognizes from where installed packages were originally installed from after selectively install packages from a number of different vendors. I don't see a good solution to this problem since the rpmdb doesn't keep track of this sort of information. The closest thing that can be used to aid this sort of update is gpg signatures. -jef From brilong at cisco.com Thu Dec 29 20:50:57 2005 From: brilong at cisco.com (Brian Long) Date: Thu, 29 Dec 2005 15:50:57 -0500 Subject: FC5 and Yum Plugins In-Reply-To: <604aa7910512291228q322ed93awd3df7442aca9c438@mail.gmail.com> References: <1135866089.4433.35.camel@brilong-lnx> <604aa7910512290828n760cd03en3b5c7bd87c5fa55a@mail.gmail.com> <1135875044.4433.52.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> <20051229193958.GC4833@neu.nirvana> <604aa7910512291149x75ca6dc9g22d6b7149943f2d5@mail.gmail.com> <20051229200744.GE4833@neu.nirvana> <604aa7910512291228q322ed93awd3df7442aca9c438@mail.gmail.com> Message-ID: <1135889457.4433.89.camel@brilong-lnx> On Thu, 2005-12-29 at 15:28 -0500, Jeff Spaleta wrote: > On 12/29/05, Axel Thimm wrote: > > That sounds too sneaky. While such a setup would generate grand > > headaches to most 3rd party repos (if not all, if there any big one > > w/o replacements?) as you and Thorsten already outlined (so it's > > better not to get as far as to have this as a default), I'd rather > > find a different solution to this problem, and I believe the other 3rd > > party repo maintainers would feel the same. It's not a repository war > > to invent new ways of dumping the other side (I hope). > > > > Certainly this kind of yum setup would not be a supported setup by the > > repos needing these replacements, so either way you look at it, this > > idiom cannot be welcomed by any such repo. In fact it would make yum > > itself as a depsolver unusable for these repos. > > > > So to answer your question directly: ATrpms would try to avoid such a > > setup by all (fair) means, and not having ATrpms at all on your client > > system would be a preferable setup to one with broken dependencies. > > > I think protectbase by default is a particularly bad idea for a number > of reasons. But if i understand the original poster correctly, the > problem he wants solved is a way to easily update packages in a way > that recognizes from where installed packages were originally > installed from after selectively install packages from a number of > different vendors. I don't see a good solution to this problem since > the rpmdb doesn't keep track of this sort of information. The closest > thing that can be used to aid this sort of update is gpg signatures. This summary is correct. If I came across an RPM in ATRPMS that required the updated xorg-X11 packages, I'd have to manually turn off protection for the base repo from Fedora and then install things. In my limited use of ATRPMS (for MythTV, its requirements and NVidia binary drivers), I prefer to stick as close to Fedora base as possible. The current situation lends itself to Fedora packages being replaced with ATRPMS packages on a whim instead of via explicit requires (in my "yum update" scenario). I'm just opining that this is not ideal. /Brian/ -- Brian Long | | | IT Data Center Systems | .|||. .|||. Cisco Linux Developer | ..:|||||||:...:|||||||:.. Phone: (919) 392-7363 | C i s c o S y s t e m s From Axel.Thimm at ATrpms.net Thu Dec 29 20:52:06 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Thu, 29 Dec 2005 21:52:06 +0100 Subject: FC5 and Yum Plugins In-Reply-To: <604aa7910512291228q322ed93awd3df7442aca9c438@mail.gmail.com> References: <1135866089.4433.35.camel@brilong-lnx> <604aa7910512290828n760cd03en3b5c7bd87c5fa55a@mail.gmail.com> <1135875044.4433.52.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> <20051229193958.GC4833@neu.nirvana> <604aa7910512291149x75ca6dc9g22d6b7149943f2d5@mail.gmail.com> <20051229200744.GE4833@neu.nirvana> <604aa7910512291228q322ed93awd3df7442aca9c438@mail.gmail.com> Message-ID: <20051229205206.GG4833@neu.nirvana> On Thu, Dec 29, 2005 at 03:28:34PM -0500, Jeff Spaleta wrote: > I think protectbase by default is a particularly bad idea for a > number of reasons. But if i understand the original poster > correctly, the problem he wants solved is a way to easily update > packages in a way that recognizes from where installed packages were > originally installed from after selectively install packages from a > number of different vendors. I don't see a good solution to this > problem since the rpmdb doesn't keep track of this sort of > information. The closest thing that can be used to aid this sort of > update is gpg signatures. I agree, this is a different problem at all. But even then I would reconsider. Assume package foo exiting at ATrpms at FC time, and then it makes it into FC core. You wouldn't want to exclude the upgrade path to another repo. Also some packages may be dropped by FC like pine was, and it may reappear in another repo. Again, you'd like to have upgrade paths not accidentially broken due to vendor/origin lock mechanisms. I think these idioms are trying to cure something at the wrong end. I'd ask the following: o What needs to be fixed? o Is it really broken (how many reports have there been on this causing a real issue)? o Can't it be fixed at the root instead of juggling with preferences, weighing, scoring, repo/disto/origin locking and the same? That's certainly something many people see differently and that must be taken into account. There are also different roles. The sysadmin guy will need a stable repo which guarantees non-breakage (and he will probably not use FC but RHEL and clones, but anyway). The desktop homeuser guy will be more open to less tested packages and more functionality and so on. I think this is best served in a stability graded repo. E.g. ATrpms has stable, testing and bleeding (it used to have 5 classifications!), kde-redhat has similar staging, and most other repos have a two classed stability categorization by now. Using these stability grading makes it easy to have fast QA on packages (they enter bleeding, get promoted to testing and later stable, similar to rawhide -> updates-testing -> updates QA, only that it happens on the same distribution 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 jeff.pitman at gmail.com Fri Dec 30 03:01:10 2005 From: jeff.pitman at gmail.com (Jeff Pitman) Date: Fri, 30 Dec 2005 11:01:10 +0800 Subject: FC5 and Yum Plugins In-Reply-To: <604aa7910512291149x75ca6dc9g22d6b7149943f2d5@mail.gmail.com> References: <1135866089.4433.35.camel@brilong-lnx> <604aa7910512290828n760cd03en3b5c7bd87c5fa55a@mail.gmail.com> <1135875044.4433.52.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> <20051229193958.GC4833@neu.nirvana> <604aa7910512291149x75ca6dc9g22d6b7149943f2d5@mail.gmail.com> Message-ID: <6b9c17630512291901x4c16e064y5b3589db869f12c9@mail.gmail.com> On 12/30/05, Jeff Spaleta wrote: > On 12/29/05, Axel Thimm wrote: > > Exactly. Which is why any repo, be it atrpms or something else, that > > does see a need to replace package foo in core, and thus has > > overlapping package sets with core will not like this idiom. I have > > already been hit by bug reports that stem from improper use of > > priorities/weights and scores. Such filtering creates a lot more > > issues and debugging problems than it solves. > > let's be clear.... if protectbase plugin was turned on by default > would atrpm leave it enabled on client system or would you attempt to > disable the plugin via package scriptlet action? For me, if someone wanted to use pyvault, I wouldn't automatically disable it. But, I would have to document very prominently that if the user wanted to use pyvault, they'd have to turn this off. And, it'd be a FAQ, for sure. -- -jeff From sundaram at redhat.com Fri Dec 30 03:04:36 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 30 Dec 2005 08:34:36 +0530 Subject: FC5 and Yum Plugins In-Reply-To: <6b9c17630512291901x4c16e064y5b3589db869f12c9@mail.gmail.com> References: <1135866089.4433.35.camel@brilong-lnx> <604aa7910512290828n760cd03en3b5c7bd87c5fa55a@mail.gmail.com> <1135875044.4433.52.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> <20051229193958.GC4833@neu.nirvana> <604aa7910512291149x75ca6dc9g22d6b7149943f2d5@mail.gmail.com> <6b9c17630512291901x4c16e064y5b3589db869f12c9@mail.gmail.com> Message-ID: <43B4A3C4.7080407@redhat.com> Jeff Pitman wrote: >On 12/30/05, Jeff Spaleta wrote: > > >>On 12/29/05, Axel Thimm wrote: >> >> >>>Exactly. Which is why any repo, be it atrpms or something else, that >>>does see a need to replace package foo in core, and thus has >>>overlapping package sets with core will not like this idiom. I have >>>already been hit by bug reports that stem from improper use of >>>priorities/weights and scores. Such filtering creates a lot more >>>issues and debugging problems than it solves. >>> >>> >>let's be clear.... if protectbase plugin was turned on by default >>would atrpm leave it enabled on client system or would you attempt to >>disable the plugin via package scriptlet action? >> >> > >For me, if someone wanted to use pyvault, I wouldn't automatically >disable it. But, I would have to document very prominently that if the >user wanted to use pyvault, they'd have to turn this off. And, it'd be >a FAQ, for sure. > > So would third party repository maintainers consider Fedora Core having protectbase by enabled acceptable?. Would it better to document the exist the functionality provided by protectbase plugin within the Fedora release notes and let users configure it for themselves? -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From Axel.Thimm at ATrpms.net Fri Dec 30 04:19:04 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 30 Dec 2005 05:19:04 +0100 Subject: FC5 and Yum Plugins In-Reply-To: <43B4A3C4.7080407@redhat.com> References: <1135866089.4433.35.camel@brilong-lnx> <604aa7910512290828n760cd03en3b5c7bd87c5fa55a@mail.gmail.com> <1135875044.4433.52.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> <20051229193958.GC4833@neu.nirvana> <604aa7910512291149x75ca6dc9g22d6b7149943f2d5@mail.gmail.com> <6b9c17630512291901x4c16e064y5b3589db869f12c9@mail.gmail.com> <43B4A3C4.7080407@redhat.com> Message-ID: <20051230041904.GA22122@neu.nirvana> On Fri, Dec 30, 2005 at 08:34:36AM +0530, Rahul Sundaram wrote: > So would third party repository maintainers consider Fedora Core > having protectbase by enabled acceptable?. I think the thread's consensus is that this would not benefit anyone as much as it puts pain to the 3rd party folks (maintainers and users). -- 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 jeff.pitman at gmail.com Fri Dec 30 04:31:11 2005 From: jeff.pitman at gmail.com (Jeff Pitman) Date: Fri, 30 Dec 2005 12:31:11 +0800 Subject: FC5 and Yum Plugins In-Reply-To: <20051230041904.GA22122@neu.nirvana> References: <1135866089.4433.35.camel@brilong-lnx> <604aa7910512290828n760cd03en3b5c7bd87c5fa55a@mail.gmail.com> <1135875044.4433.52.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> <20051229193958.GC4833@neu.nirvana> <604aa7910512291149x75ca6dc9g22d6b7149943f2d5@mail.gmail.com> <6b9c17630512291901x4c16e064y5b3589db869f12c9@mail.gmail.com> <43B4A3C4.7080407@redhat.com> <20051230041904.GA22122@neu.nirvana> Message-ID: <6b9c17630512292031i7c9404c9r70a8cddb78567f07@mail.gmail.com> On 12/30/05, Axel Thimm wrote: > On Fri, Dec 30, 2005 at 08:34:36AM +0530, Rahul Sundaram wrote: > > So would third party repository maintainers consider Fedora Core > > having protectbase by enabled acceptable?. > > I think the thread's consensus is that this would not benefit anyone > as much as it puts pain to the 3rd party folks (maintainers and > users). Yep. I mean, it's not to say the plugin is bunk. But, having it on by default causes an extra burden of support on both sides: core and "alternatives". A user activating it means that they know what they're doing, requiring much less support. -- -jeff From sundaram at redhat.com Fri Dec 30 04:34:27 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 30 Dec 2005 10:04:27 +0530 Subject: FC5 and Yum Plugins In-Reply-To: <20051230041904.GA22122@neu.nirvana> References: <1135866089.4433.35.camel@brilong-lnx> <604aa7910512290828n760cd03en3b5c7bd87c5fa55a@mail.gmail.com> <1135875044.4433.52.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> <20051229193958.GC4833@neu.nirvana> <604aa7910512291149x75ca6dc9g22d6b7149943f2d5@mail.gmail.com> <6b9c17630512291901x4c16e064y5b3589db869f12c9@mail.gmail.com> <43B4A3C4.7080407@redhat.com> <20051230041904.GA22122@neu.nirvana> Message-ID: <43B4B8D3.2060608@redhat.com> Axel Thimm wrote: >On Fri, Dec 30, 2005 at 08:34:36AM +0530, Rahul Sundaram wrote: > > >>So would third party repository maintainers consider Fedora Core >>having protectbase by enabled acceptable?. >> >> > >I think the thread's consensus is that this would not benefit anyone >as much as it puts pain to the 3rd party folks (maintainers and >users). > > Considering that this request came from one of the third party repository users I wouldnt be quick to dismiss that. If the plugin is in FC and the repository maintainers add the information to disable it for their users instead of disabling it through RPM then it could potentially help users make a more informed decision on letting repositories replace packages. -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From Axel.Thimm at ATrpms.net Fri Dec 30 04:48:21 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 30 Dec 2005 05:48:21 +0100 Subject: FC5 and Yum Plugins In-Reply-To: <43B4B8D3.2060608@redhat.com> References: <1135866089.4433.35.camel@brilong-lnx> <604aa7910512290828n760cd03en3b5c7bd87c5fa55a@mail.gmail.com> <1135875044.4433.52.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> <20051229193958.GC4833@neu.nirvana> <604aa7910512291149x75ca6dc9g22d6b7149943f2d5@mail.gmail.com> <6b9c17630512291901x4c16e064y5b3589db869f12c9@mail.gmail.com> <43B4A3C4.7080407@redhat.com> <20051230041904.GA22122@neu.nirvana> <43B4B8D3.2060608@redhat.com> Message-ID: <20051230044821.GA29376@neu.nirvana> On Fri, Dec 30, 2005 at 10:04:27AM +0530, Rahul Sundaram wrote: > Axel Thimm wrote: > >On Fri, Dec 30, 2005 at 08:34:36AM +0530, Rahul Sundaram wrote: > >>So would third party repository maintainers consider Fedora Core > >>having protectbase by enabled acceptable?. > > > >I think the thread's consensus is that this would not benefit anyone > >as much as it puts pain to the 3rd party folks (maintainers and > >users). > > > Considering that this request came from one of the third party > repository users I wouldnt be quick to dismiss that. If the plugin is in > FC and the repository maintainers add the information to disable it for > their users instead of disabling it through RPM then it could > potentially help users make a more informed decision on letting > repositories replace packages. And generate more support issues with the 3rd party repos. Yum is already creating support headaches with the --enable=foo switch, and having this being the default will not make it easier on us. Do you want 3rd parties to support Fedora Core? Then consider whether you want to make is easier or more difficult for those repositores to operate properly. And don't forget: We're talking about fixing something that isn't broken ... -- 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 redhat.com Fri Dec 30 04:53:40 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 30 Dec 2005 10:23:40 +0530 Subject: FC5 and Yum Plugins In-Reply-To: <20051230044821.GA29376@neu.nirvana> References: <1135866089.4433.35.camel@brilong-lnx> <604aa7910512290828n760cd03en3b5c7bd87c5fa55a@mail.gmail.com> <1135875044.4433.52.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> <20051229193958.GC4833@neu.nirvana> <604aa7910512291149x75ca6dc9g22d6b7149943f2d5@mail.gmail.com> <6b9c17630512291901x4c16e064y5b3589db869f12c9@mail.gmail.com> <43B4A3C4.7080407@redhat.com> <20051230041904.GA22122@neu.nirvana> <43B4B8D3.2060608@redhat.com> <20051230044821.GA29376@neu.nirvana> Message-ID: <43B4BD54.8080600@redhat.com> Hi >And generate more support issues with the 3rd party repos. Yum is >already creating support headaches with the --enable=foo switch, and >having this being the default will not make it easier on us. > >Do you want 3rd parties to support Fedora Core? Then consider whether >you want to make is easier or more difficult for those repositores to >operate properly. > > > I dont use them so I am neutral on that. Only talking about users here. >And don't forget: We're talking about fixing something that isn't >broken ... > > Getting bug reports based on packages being replaced isnt exactly a non issue. -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From andrews at byteline.com.au Fri Dec 30 05:04:35 2005 From: andrews at byteline.com.au (Andrew Stephen) Date: Fri, 30 Dec 2005 13:04:35 +0800 Subject: Using yum to Update to Development Message-ID: <004e01c60cfe$87649420$6c01a8c0@21stcenturybusiness.local> Hi I am trying to use yum to update one of my FC4 boxes to latest set of development packages. However it fails on a number of dependencies and I can't seem get around them even by installing them manually. Is there any documentation outlining the steps on upgrade from FC4 to the development packages. libssl.so.5 and libcrypto.so.5 seems causing most of the problems. --> Running transaction check --> Processing Dependency: libssl.so.5 for package: proftpd --> Processing Dependency: libcrypto.so.5 for package: proftpd --> Finished Dependency Resolution Error: Missing Dependency: libssl.so.5 is needed by package proftpd Error: Missing Dependency: libcrypto.so.5 is needed by package proftpd Cheers Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From sundaram at redhat.com Fri Dec 30 05:05:47 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Fri, 30 Dec 2005 10:35:47 +0530 Subject: Using yum to Update to Development In-Reply-To: <004e01c60cfe$87649420$6c01a8c0@21stcenturybusiness.local> References: <004e01c60cfe$87649420$6c01a8c0@21stcenturybusiness.local> Message-ID: <43B4C02B.8020108@redhat.com> Andrew Stephen wrote: > Hi > > I am trying to use yum to update one of my FC4 boxes to latest set of > development packages. However it fails on a number of dependencies and > I can't seem get around them even by installing them manually. Is > there any documentation outlining the steps on upgrade from FC4 to the > development packages. libssl.so.5 and libcrypto.so.5 seems causing > most of the problems. > > --> Running transaction check > --> Processing Dependency: libssl.so.5 for package: proftpd > --> Processing Dependency: libcrypto.so.5 for package: proftpd > --> Finished Dependency Resolution > Error: Missing Dependency: libssl.so.5 is needed by package proftpd > Error: Missing Dependency: libcrypto.so.5 is needed by package proftpd > Proftpd seems to be using older libs not available in the current development tree. yum remove proftpd and try again. Kindly post to fedora-test list for such questions in the future. Also see http://fedoraproject.org/wiki/Docs/Drafts/TestingGuide -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From nicu_fedora at nicubunu.ro Fri Dec 30 06:33:34 2005 From: nicu_fedora at nicubunu.ro (Nicu Buculei) Date: Fri, 30 Dec 2005 08:33:34 +0200 Subject: OOo 2.0 with Bluecurve icon set In-Reply-To: <3adc77210512290911g7284bcdcn8dc5672028ac26fb@mail.gmail.com> References: <43B3403E.3080703@vip.hr> <43B3AAF0.5080408@nicubunu.ro> <3adc77210512290911g7284bcdcn8dc5672028ac26fb@mail.gmail.com> Message-ID: <43B4D4BE.6090605@nicubunu.ro> Naheem Zaffar wrote: > If the iconset is not complete, maybe it would be a good idea for redhat > to donate them as a contribution to the tango-project? I do think those are not be useful for Tango: they have different guidelines, different color palette, different drawing style. > There many eyes may be able to complete the set, and allow it for use > across many desktops? Is Tango something more than a Novell only project? I am not aware of an "official" position of Fedora regarding Tango. > (having a look at the Tango-project, I think some icons there are fugly. > Hopefully as a bi-product, those would be replaced by the better ones in > the bluecurve set... All icons there seem to be head-on, with the light > source directly above, so that may clash...) -- nicu my hats collection: http://fedora.nicubunu.ro/hats/ Open Clip Art Library: http://www.openclipart.org my Fedora stuff: http://fedora.nicubunu.ro From buildsys at redhat.com Fri Dec 30 08:04:50 2005 From: buildsys at redhat.com (Build System) Date: Fri, 30 Dec 2005 03:04:50 -0500 Subject: rawhide report: 20051230 changes Message-ID: <200512300804.jBU84obE031633@porkchop.devel.redhat.com> Updated Packages: kernel-2.6.14-1.1800_FC5 ------------------------ * Thu Dec 29 2005 Dave Jones - 2.6.15-rc7-git3 - Further cfq/ub spinlock fixing. Broken deps for i386 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1796_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel = 0:2.6.14-1.1796_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires kernel-smp = 0:2.6.14-1.1796_FC5 GFS-kernel-smp - 2.6.14.1-20051219.162641.FC5.6.i686 requires /lib/modules/2.6.14-1.1796_FC5smp cman-kernel - 2.6.14.1-20051219.162641.FC5.5.i686 requires /lib/modules/2.6.14-1.1796_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.5.i686 requires kernel = 0:2.6.14-1.1796_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.5.i686 requires kernel-smp = 0:2.6.14-1.1796_FC5 cman-kernel-smp - 2.6.14.1-20051219.162641.FC5.5.i686 requires /lib/modules/2.6.14-1.1796_FC5smp dlm-kernel - 2.6.14.1-20051219.162641.FC5.5.i686 requires /lib/modules/2.6.14-1.1796_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.5.i686 requires kernel = 0:2.6.14-1.1796_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.5.i686 requires kernel-smp = 0:2.6.14-1.1796_FC5 dlm-kernel-smp - 2.6.14.1-20051219.162641.FC5.5.i686 requires /lib/modules/2.6.14-1.1796_FC5smp gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.28.i686 requires /lib/modules/2.6.14-1.1796_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.28.i686 requires kernel = 0:2.6.14-1.1796_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.28.i686 requires kernel-smp = 0:2.6.14-1.1796_FC5 gnbd-kernel-smp - 2.6.14.0-20051108.134753.FC5.12.28.i686 requires /lib/modules/2.6.14-1.1796_FC5smp jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 Broken deps for ia64 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) Broken deps for s390 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 systemtap - 0.5.2-2.s390 requires kernel >= 0:2.6.9-11 systemtap - 0.5.2-2.s390 requires kernel-devel Broken deps for s390x ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) systemtap - 0.5.2-2.s390x requires kernel >= 0:2.6.9-11 systemtap - 0.5.2-2.s390x requires kernel-devel Broken deps for x86_64 ---------------------------------------------------------- GFS-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires /lib/modules/2.6.14-1.1796_FC5 GFS-kernel - 2.6.14.1-20051219.162641.FC5.6.x86_64 requires kernel = 0:2.6.14-1.1796_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.5.x86_64 requires /lib/modules/2.6.14-1.1796_FC5 cman-kernel - 2.6.14.1-20051219.162641.FC5.5.x86_64 requires kernel = 0:2.6.14-1.1796_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.5.x86_64 requires /lib/modules/2.6.14-1.1796_FC5 dlm-kernel - 2.6.14.1-20051219.162641.FC5.5.x86_64 requires kernel = 0:2.6.14-1.1796_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.28.x86_64 requires /lib/modules/2.6.14-1.1796_FC5 gnbd-kernel - 2.6.14.0-20051108.134753.FC5.12.28.x86_64 requires kernel = 0:2.6.14-1.1796_FC5 jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) From jarod at wilsonet.com Fri Dec 30 09:01:11 2005 From: jarod at wilsonet.com (Jarod Wilson) Date: Fri, 30 Dec 2005 01:01:11 -0800 Subject: FC5 and Yum Plugins In-Reply-To: <1135876680.2665.13.camel@localhost.localdomain> References: <1135866089.4433.35.camel@brilong-lnx> <1135875044.4433.52.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> Message-ID: <200512300101.13937.jarod@wilsonet.com> On Thursday 29 December 2005 09:18, Thorsten Leemhuis wrote: > Am Donnerstag, den 29.12.2005, 11:50 -0500 schrieb Brian Long: > > On Thu, 2005-12-29 at 11:28 -0500, Jeff Spaleta wrote: > > > On 12/29/05, Brian Long wrote: > > > > I would think it would be in the best interest of the Fedora team to > > > > install protectbase by default, enable it and protect Fedora repos. > > > > If power users want to disable it, it's very easy. > > > > Am I off-base in this request? :) > > > > > > Have you spoken with the atrpms and freshrpms maintainers? Do you have > > > their agreement that turning this on is in the best interest of their > > > users? > > > > Nope. I don't know that it's up to me or the Fedora project to contact > > each third-party repo maintainer when Fedora implements a change. I'm > > asking Fedora to consider a change. If Fedora decides to implement that > > change for the "protection" of their users and repos, the third party > > repos would shoot themselves in the foot if they started scripting > > around the protection! IMHO, they would lose credibility. > > They don't override base Fedora RPMs just for fun, they afaik do it > because some of the their packages need fixes and/or enhancements that > are not in the base Fedora RPMs (correct me if I'm wrong here). > > So if you protect the Core packages some packages in the 3rd-Party might > not work (or not perfectly). So it probably creates more problems for > the user and the 3rd party repo maintainer than it solves. > > > I believe there are 2 types of 3rd party repo users: > > > > 1) Fedora user who needs 3rd party repos for certain apps but never > > wants that repo to override base Fedora RPMs > > Then use a 3rd party repo that does not override Fedora Core or Extras > RPMS. Yes, such a repo exists, but no, I still has no mythtv -- nobody > stepped up to package it there. Any volunteers? /me raises hand. :) I already have a fair amount of involvement with mythtv as maintainer of its stable code branch and my work on the ATrpms-provided mythtv packages. Unfortunately, there are some issues of reality to deal with. I'd love to see mythtv into Extras and, but the mythtv source code itself contains ffmpeg, which itself is already banished from Extras. Personally, I really like the protectbase option. Anyone that doesn't want a 3rd-party repo replacing core packages can just enable that instead of complaining about how repository X replaces core packages. Then its their explicit choice to replace a core package. Along the lines of yum's --enablerepo/--disablerepo options, maybe a '--noprotectbase' option to temporarily disable protectbase and install a package or three that replaces a core package without having to download and install it manually. Another idea might be to include "packages excluded by protectbase" in the pre-install confirmation summary... -- Jarod Wilson jarod at wilsonet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jarod at wilsonet.com Fri Dec 30 09:05:46 2005 From: jarod at wilsonet.com (Jarod Wilson) Date: Fri, 30 Dec 2005 01:05:46 -0800 Subject: FC5 and Yum Plugins In-Reply-To: <43B4BD54.8080600@redhat.com> References: <1135866089.4433.35.camel@brilong-lnx> <20051230044821.GA29376@neu.nirvana> <43B4BD54.8080600@redhat.com> Message-ID: <200512300105.46461.jarod@wilsonet.com> On Thursday 29 December 2005 20:53, Rahul Sundaram wrote: > >And generate more support issues with the 3rd party repos. Yum is > >already creating support headaches with the --enable=foo switch, and > >having this being the default will not make it easier on us. > > > >Do you want 3rd parties to support Fedora Core? Then consider whether > >you want to make is easier or more difficult for those repositores to > >operate properly. > > I dont use them so I am neutral on that. Only talking about users here. I'm in the position of being both a user and a contributor to one of said 3rd-party repositories[1]. I definitely still want to support Fedora Core. > >And don't forget: We're talking about fixing something that isn't > >broken ... > > Getting bug reports based on packages being replaced isnt exactly a non > issue. Axel, I have to agree with Rahul here. While it isn't "broken", per se, its definitely an issue. There are quite a few people who are rather adverse to the way ATrpms, if enabled in full, replaces core packages, but still want to use a number of ATrpms packages. I know that (at least most of ;) the reasons for ATrpms replacing core packages are pure, at least from ATrpms' point of view, but there's something to be said for only upgrading what *must* be upgraded to add a new program. I think the majority of users who complain about ATrpms replacing core packages are what I'd call power-users, who are bright enough to enable protectbase for themselves, so protectbase off by default sounds reasonable to me. I think it gives those power-users what they want, and minimizes headaches for 3rd-party repo maintainers from sheeple who just want an mp3 player (or mythtv ;). [1] Disclaimer: I do a bit of packaging work for ATrpms. -- Jarod Wilson jarod at wilsonet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From jarod at wilsonet.com Fri Dec 30 09:17:38 2005 From: jarod at wilsonet.com (Jarod Wilson) Date: Fri, 30 Dec 2005 01:17:38 -0800 Subject: FC5 and Yum Plugins In-Reply-To: <200512300101.13937.jarod@wilsonet.com> References: <1135866089.4433.35.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> <200512300101.13937.jarod@wilsonet.com> Message-ID: <200512300117.38566.jarod@wilsonet.com> On Friday 30 December 2005 01:01, Jarod Wilson wrote: > On Thursday 29 December 2005 09:18, Thorsten Leemhuis wrote: [...] > > Then use a 3rd party repo that does not override Fedora Core or Extras > > RPMS. Yes, such a repo exists, but no, I still has no mythtv -- nobody > > stepped up to package it there. Any volunteers? > > /me raises hand. :) > > I already have a fair amount of involvement with mythtv as maintainer of > its stable code branch and my work on the ATrpms-provided mythtv packages. > Unfortunately, there are some issues of reality to deal with. I'd love to > see mythtv into Extras and, but the mythtv source code itself contains > ffmpeg, which itself is already banished from Extras. Whoops, misread what Thorsten said, I think. I don't think he was advocating for mythtv into Extras, he was talking about putting it into another repo. What's wrong with the ATrpms version? Is it simply a matter of principle that people refuse to use the ATrpms package(s), since ATrpms can/does override core packages? A protectbase option seems like an idea solution for that, so why dismiss it w/"use a repo that doesn't override"... -- Jarod Wilson jarod at wilsonet.com -------------- 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 j2solutions.net Fri Dec 30 09:27:33 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 30 Dec 2005 01:27:33 -0800 Subject: FC5 and Yum Plugins In-Reply-To: <200512300117.38566.jarod@wilsonet.com> References: <1135866089.4433.35.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> <200512300101.13937.jarod@wilsonet.com> <200512300117.38566.jarod@wilsonet.com> Message-ID: <1135934854.2929.5.camel@yoda.loki.me> On Fri, 2005-12-30 at 01:17 -0800, Jarod Wilson wrote: > Whoops, misread what Thorsten said, I think. I don't think he was advocating > for mythtv into Extras, he was talking about putting it into another repo. > What's wrong with the ATrpms version? Is it simply a matter of principle that > people refuse to use the ATrpms package(s), since ATrpms can/does override > core packages? A protectbase option seems like an idea solution for that, so > why dismiss it w/"use a repo that doesn't override"... > The question is, what good is this plugin doing? If you enable a 3rd party repo, to get something like MythTV, you'll need to get the deps. If the deps happen to replace core/extras packages, then they do. They are necessary for the software you are asking to install. So you're going to override it to install your software. This is in the install context. In the update context, then sure if the 3rd party repo nvr for a package is higher than the nvr for the core/extras package then this plugin might be useful to ignore that, unless ignoring would break deps with something like MythTV. Seems to me that there should be a different method than just protecting core/extras. Seems the 'protection' should be based around replacing for no other reason than nvr comparison. If the replacement is pulled in for an honest dep satisfaction, rather than just a higher nvr comparison, then it should be allowed. Otherwise prompt user or block. This keeps 3rd party repos working properly and keeps users systems as close to strict core/extras as possible w/out breaking user installed software. -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 Fri Dec 30 09:34:53 2005 From: fedora at leemhuis.info (Thorsten Leemhuis) Date: Fri, 30 Dec 2005 10:34:53 +0100 Subject: FC5 and Yum Plugins In-Reply-To: <200512300117.38566.jarod@wilsonet.com> References: <1135866089.4433.35.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> <200512300101.13937.jarod@wilsonet.com> <200512300117.38566.jarod@wilsonet.com> Message-ID: <1135935293.12756.17.camel@thl.ct.heise.de> Am Freitag, den 30.12.2005, 01:17 -0800 schrieb Jarod Wilson: > On Friday 30 December 2005 01:01, Jarod Wilson wrote: > > On Thursday 29 December 2005 09:18, Thorsten Leemhuis wrote: > [...] > > > Then use a 3rd party repo that does not override Fedora Core or Extras > > > RPMS. Yes, such a repo exists, but no, I still has no mythtv -- nobody > > > stepped up to package it there. Any volunteers? > > /me raises hand. :) > >[...] > Whoops, misread what Thorsten said, I think. I don't think he was advocating > for mythtv into Extras, he was talking about putting it into another repo. Yes. Livna to be precise. > What's wrong with the ATrpms version? Don't know, I never used any version of mythtv. > Is it simply a matter of principle that > people refuse to use the ATrpms package(s), since ATrpms can/does override > core packages? You have to ask people. But if you ask me: Yes, that would be a problem for me if I would like to use mythtv or other stuff from ATrpms. That's one of the reasons why livna exists afaics. And I really would like to see mythtv in livna. Some work has already been done to achieve that, but nobody did enough and submitted it for QA to livna. CU thl From jarod at wilsonet.com Fri Dec 30 09:44:51 2005 From: jarod at wilsonet.com (Jarod Wilson) Date: Fri, 30 Dec 2005 01:44:51 -0800 Subject: FC5 and Yum Plugins In-Reply-To: <1135934854.2929.5.camel@yoda.loki.me> References: <1135866089.4433.35.camel@brilong-lnx> <200512300117.38566.jarod@wilsonet.com> <1135934854.2929.5.camel@yoda.loki.me> Message-ID: <200512300144.51871.jarod@wilsonet.com> On Friday 30 December 2005 01:27, Jesse Keating wrote: > On Fri, 2005-12-30 at 01:17 -0800, Jarod Wilson wrote: > > Whoops, misread what Thorsten said, I think. I don't think he was > > advocating for mythtv into Extras, he was talking about putting it into > > another repo. What's wrong with the ATrpms version? Is it simply a matter > > of principle that people refuse to use the ATrpms package(s), since > > ATrpms can/does override core packages? A protectbase option seems like > > an idea solution for that, so why dismiss it w/"use a repo that doesn't > > override"... > > The question is, what good is this plugin doing? If you enable a 3rd > party repo, to get something like MythTV, you'll need to get the deps. > If the deps happen to replace core/extras packages, then they do. They > are necessary for the software you are asking to install. So you're > going to override it to install your software. This is in the install > context. In the update context, then sure if the 3rd party repo nvr for > a package is higher than the nvr for the core/extras package then this > plugin might be useful to ignore that, unless ignoring would break deps > with something like MythTV. Seems to me that there should be a > different method than just protecting core/extras. Seems the > 'protection' should be based around replacing for no other reason than > nvr comparison. If the replacement is pulled in for an honest dep > satisfaction, rather than just a higher nvr comparison, then it should > be allowed. Otherwise prompt user or block. This keeps 3rd party repos > working properly and keeps users systems as close to strict core/extras > as possible w/out breaking user installed software. I believe you just summed up exactly what I'd more or less ideally like to see out of this, just much more clearly so. :) I'd definitely agree that not core-stomping is a much more relevant issue when it comes to an upgrade than an install of new software. On a new install via yum, you get asked if you really want to install, with it shown plain as day what repo packages are coming from. Though its possible that a package from core would also satisfy the dependency of a new package you've requested to install out of a 3rd-party repo, but the 3rd-party repo happens to also have a version of that dependency that's "newer", so yeah, the package you're actually requesting to install would maybe have to have an explicit Requires: >= , otherwise install core version, if it exists... (I think that's what you said too). -- Jarod Wilson jarod at wilsonet.com -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Dec 30 12:10:41 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 30 Dec 2005 13:10:41 +0100 Subject: FC5 and Yum Plugins In-Reply-To: <1135934854.2929.5.camel@yoda.loki.me> References: <1135866089.4433.35.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> <200512300101.13937.jarod@wilsonet.com> <200512300117.38566.jarod@wilsonet.com> <1135934854.2929.5.camel@yoda.loki.me> Message-ID: <20051230121041.GA3297@neu.nirvana> On Fri, Dec 30, 2005 at 01:27:33AM -0800, Jesse Keating wrote: > On Fri, 2005-12-30 at 01:17 -0800, Jarod Wilson wrote: > The question is, what good is this plugin doing? If you enable a > 3rd party repo, to get something like MythTV, you'll need to get the > deps. If the deps happen to replace core/extras packages, then they > do. They are necessary for the software you are asking to install. > So you're going to override it to install your software. This is in > the install context. In the update context, then sure if the 3rd > party repo nvr for a package is higher than the nvr for the > core/extras package then this plugin might be useful to ignore that, > unless ignoring would break deps with something like MythTV. Seems > to me that there should be a different method than just protecting > core/extras. Seems the 'protection' should be based around > replacing for no other reason than nvr comparison. If the > replacement is pulled in for an honest dep satisfaction, rather than > just a higher nvr comparison, then it should be allowed. How would you do that w/o checking the specfile itself? If package foo from core is replaced with foo compiled with different build options, or a bugfix that is required in a context not interesting in core (so it will not make it into "updates") or similar, how can you distinguish it from arbitrary package updates? > Otherwise prompt user or block. This keeps 3rd party repos working > properly and keeps users systems as close to strict core/extras as > possible w/out breaking user installed software. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Dec 30 12:11:33 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 30 Dec 2005 13:11:33 +0100 Subject: FC5 and Yum Plugins In-Reply-To: <43B4BD54.8080600@redhat.com> References: <1135875044.4433.52.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> <20051229193958.GC4833@neu.nirvana> <604aa7910512291149x75ca6dc9g22d6b7149943f2d5@mail.gmail.com> <6b9c17630512291901x4c16e064y5b3589db869f12c9@mail.gmail.com> <43B4A3C4.7080407@redhat.com> <20051230041904.GA22122@neu.nirvana> <43B4B8D3.2060608@redhat.com> <20051230044821.GA29376@neu.nirvana> <43B4BD54.8080600@redhat.com> Message-ID: <20051230121133.GB3297@neu.nirvana> On Fri, Dec 30, 2005 at 10:23:40AM +0530, Rahul Sundaram wrote: > Hi > > >And generate more support issues with the 3rd party repos. Yum is > >already creating support headaches with the --enable=foo switch, and > >having this being the default will not make it easier on us. > > > >Do you want 3rd parties to support Fedora Core? Then consider whether > >you want to make is easier or more difficult for those repositores to > >operate properly. > > > > > > > I dont use them so I am neutral on that. Only talking about users here. > > >And don't forget: We're talking about fixing something that isn't > >broken ... > > > > > Getting bug reports based on packages being replaced isnt exactly a non > issue. Can you please point me to these bugs? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Fri Dec 30 12:13:22 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Fri, 30 Dec 2005 13:13:22 +0100 Subject: FC5 and Yum Plugins In-Reply-To: <200512300105.46461.jarod@wilsonet.com> References: <1135866089.4433.35.camel@brilong-lnx> <20051230044821.GA29376@neu.nirvana> <43B4BD54.8080600@redhat.com> <200512300105.46461.jarod@wilsonet.com> Message-ID: <20051230121322.GC3297@neu.nirvana> On Fri, Dec 30, 2005 at 01:05:46AM -0800, Jarod Wilson wrote: > On Thursday 29 December 2005 20:53, Rahul Sundaram wrote: > > >And generate more support issues with the 3rd party repos. Yum is > > >already creating support headaches with the --enable=foo switch, and > > >having this being the default will not make it easier on us. > > > > > >Do you want 3rd parties to support Fedora Core? Then consider whether > > >you want to make is easier or more difficult for those repositores to > > >operate properly. > > > > I dont use them so I am neutral on that. Only talking about users here. > > I'm in the position of being both a user and a contributor to one of said > 3rd-party repositories[1]. I definitely still want to support Fedora Core. > > > >And don't forget: We're talking about fixing something that isn't > > >broken ... > > > > Getting bug reports based on packages being replaced isnt exactly a non > > issue. > > Axel, I have to agree with Rahul here. While it isn't "broken", per se, its > definitely an issue. There are quite a few people who are rather adverse to > the way ATrpms, if enabled in full, replaces core packages, but still want to > use a number of ATrpms packages. I know that (at least most of ;) the reasons > for ATrpms replacing core packages are pure, at least from ATrpms' point of > view, but there's something to be said for only upgrading what *must* be > upgraded to add a new program. > > I think the majority of users who complain about ATrpms replacing core > packages are what I'd call power-users, who are bright enough to enable > protectbase for themselves, so protectbase off by default sounds reasonable > to me. I think it gives those power-users what they want, and minimizes > headaches for 3rd-party repo maintainers from sheeple who just want an mp3 > player (or mythtv ;). ahm, the issue is about enabling this by default, not whether it the plugin itself makes it into the release. > [1] Disclaimer: I do a bit of packaging work for ATrpms. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From wrrhdev at riede.org Fri Dec 30 13:42:13 2005 From: wrrhdev at riede.org (Willem Riede) Date: Fri, 30 Dec 2005 08:42:13 -0500 Subject: FC5 and Yum Plugins In-Reply-To: <20051230121322.GC3297@neu.nirvana> (from Axel.Thimm@ATrpms.net on Fri Dec 30 07:13:22 2005) References: <1135866089.4433.35.camel@brilong-lnx> <20051230044821.GA29376@neu.nirvana> <43B4BD54.8080600@redhat.com> <200512300105.46461.jarod@wilsonet.com> <20051230121322.GC3297@neu.nirvana> Message-ID: <1135950133l.3688l.6l@athena.riede.org> On 12/30/2005 07:13:22 AM, Axel Thimm wrote: > On Fri, Dec 30, 2005 at 01:05:46AM -0800, Jarod Wilson wrote: > > On Thursday 29 December 2005 20:53, Rahul Sundaram wrote: > > > >And generate more support issues with the 3rd party repos. Yum is > > > >already creating support headaches with the --enable=foo switch, and > > > >having this being the default will not make it easier on us. > > > > > > > >Do you want 3rd parties to support Fedora Core? Then consider whether > > > >you want to make is easier or more difficult for those repositores to > > > >operate properly. > > > > > > I dont use them so I am neutral on that. Only talking about users here. > > > > I'm in the position of being both a user and a contributor to one of said > > 3rd-party repositories[1]. I definitely still want to support Fedora Core. > > > > > >And don't forget: We're talking about fixing something that isn't > > > >broken ... > > > > > > Getting bug reports based on packages being replaced isnt exactly a non > > > issue. > > > > Axel, I have to agree with Rahul here. While it isn't "broken", per se, its > > definitely an issue. There are quite a few people who are rather adverse to > > the way ATrpms, if enabled in full, replaces core packages, but still want to > > use a number of ATrpms packages. I know that (at least most of ;) the reasons > > for ATrpms replacing core packages are pure, at least from ATrpms' point of > > view, but there's something to be said for only upgrading what *must* be > > upgraded to add a new program. > > > > I think the majority of users who complain about ATrpms replacing core > > packages are what I'd call power-users, who are bright enough to enable > > protectbase for themselves, so protectbase off by default sounds reasonable > > to me. I think it gives those power-users what they want, and minimizes > > headaches for 3rd-party repo maintainers from sheeple who just want an mp3 > > player (or mythtv ;). > > ahm, the issue is about enabling this by default, not whether it the > plugin itself makes it into the release. Jarod described my position to a T. I use some, but not all possible ATrpms, so I am grateful for Axel's work, and the last thing I want to do is alienate him or have him stop caring about fedora. While I would like the distribution to contain protectbase, I'd have no problem swithching it on, so a compromise that it is shipped disabled would be fine with me. Regards, Willem Riede. From naheemzaffar at gmail.com Fri Dec 30 13:47:52 2005 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Fri, 30 Dec 2005 13:47:52 +0000 Subject: OOo 2.0 with Bluecurve icon set In-Reply-To: <43B4D4BE.6090605@nicubunu.ro> References: <43B3403E.3080703@vip.hr> <43B3AAF0.5080408@nicubunu.ro> <3adc77210512290911g7284bcdcn8dc5672028ac26fb@mail.gmail.com> <43B4D4BE.6090605@nicubunu.ro> Message-ID: <3adc77210512300547w21774908he68fc50fc86cb8e7@mail.gmail.com> Tango-Project is a freedesktop project. I had assumed that it as not just novell involved, as creating a new complete icon set for gnome (aswell as other DE's) would have to be supported by others to become default? If its novell-centric atm, maybe some artists could broaden its horizons. (Sorry for offtopic post) Either way, the Bluecurve iconset is pretty good, and just needs small touchups (like removing the black borders IMO), and completion. Maybe set up an alternative icon theme under Tango-Project? (Sorry if it sounds preachy. I am not an artist, but am just throwing ideas around. Others probably have thought along same lines, but not aired them? (I do not think I am that original in my thoughts)) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpeters at mac.com Fri Dec 30 13:57:14 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 30 Dec 2005 05:57:14 -0800 Subject: FC5 and Yum Plugins In-Reply-To: <200512300105.46461.jarod@wilsonet.com> References: <1135866089.4433.35.camel@brilong-lnx> <20051230044821.GA29376@neu.nirvana> <43B4BD54.8080600@redhat.com> <200512300105.46461.jarod@wilsonet.com> Message-ID: <1135951034.1012.3.camel@locolhost.localdomain> On Fri, 2005-12-30 at 01:05 -0800, Jarod Wilson wrote: > > Axel, I have to agree with Rahul here. While it isn't "broken", per se, its > definitely an issue. There are quite a few people who are rather adverse to > the way ATrpms, if enabled in full, replaces core packages, but still want to > use a number of ATrpms packages. smart does an excellent job at that - you can give third party repositories a lower priority than base/updates/extras - but give individual packages within the third party repositories a higher priority. I would suggest that people who want to use third party repositories use something like smart (which is available from the third party repositories, and I think I saw it recently being reviewed for Extras) opposed to yum. With that in mind, yum plugins that are disabled/enabled won't matter, since yum won't be being used for that repo management. From mpeters at mac.com Fri Dec 30 14:00:49 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 30 Dec 2005 06:00:49 -0800 Subject: FC5 and Yum Plugins In-Reply-To: <1135934854.2929.5.camel@yoda.loki.me> References: <1135866089.4433.35.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> <200512300101.13937.jarod@wilsonet.com> <200512300117.38566.jarod@wilsonet.com> <1135934854.2929.5.camel@yoda.loki.me> Message-ID: <1135951249.1012.6.camel@locolhost.localdomain> On Fri, 2005-12-30 at 01:27 -0800, Jesse Keating wrote: > On Fri, 2005-12-30 at 01:17 -0800, Jarod Wilson wrote: > > Whoops, misread what Thorsten said, I think. I don't think he was advocating > > for mythtv into Extras, he was talking about putting it into another repo. > > What's wrong with the ATrpms version? Is it simply a matter of principle that > > people refuse to use the ATrpms package(s), since ATrpms can/does override > > core packages? A protectbase option seems like an idea solution for that, so > > why dismiss it w/"use a repo that doesn't override"... > > > > The question is, what good is this plugin doing? If you enable a 3rd > party repo, to get something like MythTV, you'll need to get the deps. > If the deps happen to replace core/extras packages, then they do. They > are necessary for the software you are asking to install. Not always. Sometimes the Core package is sufficient, but the third party repo has what looks like a newer release, thus updating the core package when it doesn't need to. How does the end user know the difference? From brilong at cisco.com Fri Dec 30 14:03:26 2005 From: brilong at cisco.com (Brian Long) Date: Fri, 30 Dec 2005 09:03:26 -0500 Subject: FC5 and Yum Plugins In-Reply-To: <1135950133l.3688l.6l@athena.riede.org> References: <1135866089.4433.35.camel@brilong-lnx> <20051230044821.GA29376@neu.nirvana> <43B4BD54.8080600@redhat.com> <200512300105.46461.jarod@wilsonet.com> <20051230121322.GC3297@neu.nirvana> <1135950133l.3688l.6l@athena.riede.org> Message-ID: <1135951406.5243.7.camel@brilong-lnx> On Fri, 2005-12-30 at 08:42 -0500, Willem Riede wrote: > Jarod described my position to a T. I use some, but not all possible ATrpms, > so I am grateful for Axel's work, and the last thing I want to do is alienate > him or have him stop caring about fedora. While I would like the distribution > to contain protectbase, I'd have no problem swithching it on, so a compromise > that it is shipped disabled would be fine with me. I am in the same boat with Willem. I would not be a MythTV user if it weren't for the work Axel, Jarod and others have done to make MythTV easy to install on Fedora. Thanks! I also have extensive experience with yum at work; we use it to manage over 5,000 RHEL workstations and servers. As a home user of yum, I found protectbase to be a "good thing" (tm). If it were included in FC5 but disabled, I think that would be a step in the right direction. /Brian/ -- Brian Long | | | IT Data Center Systems | .|||. .|||. Cisco Linux Developer | ..:|||||||:...:|||||||:.. Phone: (919) 392-7363 | C i s c o S y s t e m s From jspaleta at gmail.com Fri Dec 30 14:09:09 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Fri, 30 Dec 2005 09:09:09 -0500 Subject: FC5 and Yum Plugins In-Reply-To: <1135951034.1012.3.camel@locolhost.localdomain> References: <1135866089.4433.35.camel@brilong-lnx> <20051230044821.GA29376@neu.nirvana> <43B4BD54.8080600@redhat.com> <200512300105.46461.jarod@wilsonet.com> <1135951034.1012.3.camel@locolhost.localdomain> Message-ID: <604aa7910512300609yeda5f8erebfe1b36765b3792@mail.gmail.com> On 12/30/05, Michael A. Peters wrote: > smart does an excellent job at that - you can give third party > repositories a lower priority than base/updates/extras - but give > individual packages within the third party repositories a higher > priority. > > I would suggest that people who want to use third party repositories use > something like smart (which is available from the third party > repositories, and I think I saw it recently being reviewed for Extras) > opposed to yum. You are volunteering to help Axel out by responding to all the bug reports he's getting from people who are using priorities to filter out parts of atrpms? Seems only fair. Here you are delibrately encouraging people to use a method to subvert the structure of the 3rd party repository and creating an additional burden on the repo maintainers. -jef From twaugh at redhat.com Fri Dec 30 17:17:17 2005 From: twaugh at redhat.com (Tim Waugh) Date: Fri, 30 Dec 2005 17:17:17 +0000 Subject: Status of docbook to pdf toolchain on Fedora? In-Reply-To: <43B21E98.7010703@research.att.com> References: <43A99EF3.9050404@research.att.com> <20051221214325.GG16000@redhat.com> <1135207981.25397.31.camel@cassandra.boston.redhat.com> <43A9FD31.9030903@research.att.com> <1135716869.3345.3.camel@mariusa-ro.ro.oracle.com> <43B21E98.7010703@research.att.com> Message-ID: <20051230171717.GM16000@redhat.com> On Wed, Dec 28, 2005 at 12:11:52AM -0500, John Ellson wrote: > Thanks for the reference. Unfortunately it depends on pangoxsl which hasn't > been maintained since March. I can't trivially get it to build on > fedora-core-development. Perhaps I'll try a bit harder tomorrow. Last time I tried it was fairly easy. The file manifests in the shipped spec files just need fixing for the .la files, that's all. Tim. */ -------------- 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 j2solutions.net Fri Dec 30 17:32:10 2005 From: jkeating at j2solutions.net (Jesse Keating) Date: Fri, 30 Dec 2005 09:32:10 -0800 Subject: FC5 and Yum Plugins In-Reply-To: <20051230121041.GA3297@neu.nirvana> References: <1135866089.4433.35.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> <200512300101.13937.jarod@wilsonet.com> <200512300117.38566.jarod@wilsonet.com> <1135934854.2929.5.camel@yoda.loki.me> <20051230121041.GA3297@neu.nirvana> Message-ID: <1135963930.2929.11.camel@yoda.loki.me> On Fri, 2005-12-30 at 13:10 +0100, Axel Thimm wrote: > How would you do that w/o checking the specfile itself? If package foo > from core is replaced with foo compiled with different build options, > or a bugfix that is required in a context not interesting in core (so > it will not make it into "updates") or similar, how can you > distinguish it from arbitrary package updates? This I don't know. There doesn't seem to be anything currently in nvr that allows for vendor comparison. So the only thing I can think of is explicit requires on a specific package nvr that includes your vendor tag. No >< stuff, just =. Of course there may be smarter ways to do this.... -- Jesse Keating RHCE (geek.j2solutions.net) Fedora Legacy Team (www.fedoralegacy.org) GPG Public Key (geek.j2solutions.net/jkeating.j2solutions.pub) -------------- 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 naheemzaffar at gmail.com Fri Dec 30 17:32:21 2005 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Fri, 30 Dec 2005 17:32:21 +0000 Subject: FC5 and Yum Plugins In-Reply-To: <604aa7910512300609yeda5f8erebfe1b36765b3792@mail.gmail.com> References: <1135866089.4433.35.camel@brilong-lnx> <20051230044821.GA29376@neu.nirvana> <43B4BD54.8080600@redhat.com> <200512300105.46461.jarod@wilsonet.com> <1135951034.1012.3.camel@locolhost.localdomain> <604aa7910512300609yeda5f8erebfe1b36765b3792@mail.gmail.com> Message-ID: <3adc77210512300932r14da0e99l261c027e0e4abf76@mail.gmail.com> I have not used the protectbase plugin, so have a few practical questions which need to be answered even before it should be added as off by default: 1. If a package moves from a protected Core to a protected Extras, would yum function still update? 2. Vice versa? 3. If a package is dropped by fedora, and is picked up by a third party, will it update? 4.If a new package is added in extras/core that was originally in an unprotected 3rd arty repo, will it update from the 3rd party repo, or from extras/core? I would assume the plugin will break 1 and 2, but allow 4. I am not sure how 3 would work (yum does not store where the poackages were installed from. I assume it uses the lates metadata to 'guess' the repo? so if it is no longer listed by any of the fedora repo's, it may assume it was 3rd party all along? or does it use signatures?) -------------- next part -------------- An HTML attachment was scrubbed... URL: From mpeters at mac.com Fri Dec 30 17:37:52 2005 From: mpeters at mac.com (Michael A. Peters) Date: Fri, 30 Dec 2005 09:37:52 -0800 Subject: FC5 and Yum Plugins In-Reply-To: <604aa7910512300609yeda5f8erebfe1b36765b3792@mail.gmail.com> References: <1135866089.4433.35.camel@brilong-lnx> <20051230044821.GA29376@neu.nirvana> <43B4BD54.8080600@redhat.com> <200512300105.46461.jarod@wilsonet.com> <1135951034.1012.3.camel@locolhost.localdomain> <604aa7910512300609yeda5f8erebfe1b36765b3792@mail.gmail.com> Message-ID: <1135964272.7671.18.camel@locolhost.localdomain> On Fri, 2005-12-30 at 09:09 -0500, Jeff Spaleta wrote: > > You are volunteering to help Axel out by responding to all the bug > reports he's getting from people who are using priorities to filter > out parts of atrpms? Seems only fair. Here you are delibrately > encouraging people to use a method to subvert the structure of the 3rd > party repository and creating an additional burden on the repo > maintainers. When I ran a repo - I had two. One contained packages that did not conflict with core/extras One contained packages that would conflict (replace) packages in core/extras. That's really the way it should be done IMHO - so that users who don't want core/extras packages replaced don't have to, they can temporarily enable the "hot" repo for the specific needs they have (and put proper exludes in base/updates/extras). When someone has a bunch of stuff replaced from a third party repository, are they still running Fedora Core or are they running a hybrid? That's the problem I have with repositories that replace core packages. They may have more features, but I don't know that they get properly patched when vulnerabilities are found, etc. - so replacing a core package is imho a bad idea unless you know you need to. What happens when a third party repository breaks causing yum update to fail? It happens more often than it should, and it leaves users frustrated. Sometimes it can be difficult to resolve the situation. An equivalent of DLL Hell happens because of third party repositories. Not with all of them, I don't know about ATrpms - never used them, but mixing repositories often results in a broken system that can be time consuming to repair. Installing with a safety from that is a good thing - the user can still disable the safety if they want. From sundaram at redhat.com Sat Dec 31 00:48:09 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Sat, 31 Dec 2005 06:18:09 +0530 Subject: FC5 and Yum Plugins In-Reply-To: <20051230121133.GB3297@neu.nirvana> References: <1135875044.4433.52.camel@brilong-lnx> <1135876680.2665.13.camel@localhost.localdomain> <20051229193958.GC4833@neu.nirvana> <604aa7910512291149x75ca6dc9g22d6b7149943f2d5@mail.gmail.com> <6b9c17630512291901x4c16e064y5b3589db869f12c9@mail.gmail.com> <43B4A3C4.7080407@redhat.com> <20051230041904.GA22122@neu.nirvana> <43B4B8D3.2060608@redhat.com> <20051230044821.GA29376@neu.nirvana> <43B4BD54.8080600@redhat.com> <20051230121133.GB3297@neu.nirvana> Message-ID: <43B5D549.3050103@redhat.com> Hi >>Getting bug reports based on packages being replaced isnt exactly a non >>issue. >> >> > >Can you please point me to these bugs? > > I dont have any handy now but ask anyone who hangs out in #fedora for more than a week for the horror stories. -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From eric at interplas.com Sat Dec 31 05:24:30 2005 From: eric at interplas.com (Eric Wood) Date: Sat, 31 Dec 2005 00:24:30 -0500 Subject: lastest boot.iso crashes during install - possible dmraid cause Message-ID: <43B6160E.6060902@interplas.com> Just wondering if this is happening to anyone else. I grabed the lastest boot.iso from: http://distro.ibiblio.org/pub/linux/distributions/fedora/linux/core/development/i386/images/boot.iso and it crashed right at the detection of the harddisks. I'm trying to give some feedback to Peter Jones's call for dmraid testing: https://www.redhat.com/archives/fedora-devel-list/2005-December/msg00474.html Kernel crashes with and without the dmraid boot option. Just a guess but the new kernel may be trying to deal with the raid-1 metadata but I really don't know. Thanks, -eric wood Current Config: Shuttle X SFF 1.6Ghz 2 x 80 Gig SATA drives w/ BIOS fake raid-1 mirror (Via chipset) currently running FC4. From buildsys at redhat.com Sat Dec 31 08:02:10 2005 From: buildsys at redhat.com (Build System) Date: Sat, 31 Dec 2005 03:02:10 -0500 Subject: rawhide report: 20051231 changes Message-ID: <200512310802.jBV82AEP017418@porkchop.devel.redhat.com> Updated Packages: GFS-kernel-2.6.14.1-20051219.162641.FC5.7 ----------------------------------------- * Fri Dec 30 2005 Jesse Keating - rebuilt cman-kernel-2.6.14.1-20051219.162641.FC5.6 ------------------------------------------ * Fri Dec 30 2005 Jesse Keating - rebuilt dlm-kernel-2.6.14.1-20051219.162641.FC5.6 ----------------------------------------- * Fri Dec 30 2005 Jesse Keating - rebuilt eclipse-cdt-1:3.0.1-1jpp_3fc ---------------------------- * Fri Dec 30 2005 Andrew Overholt 3.0.1-1jpp_3fc - Fix %files section to not be x86-specific. gnbd-kernel-2.6.14.0-20051108.134753.FC5.12.30 ---------------------------------------------- * Fri Dec 30 2005 Jesse Keating - rebuilt kernel-2.6.14-1.1805_FC5 ------------------------ * Fri Dec 30 2005 Dave Jones - 2.6.15-rc7-git4 selinux-policy-2.1.6-19 ----------------------- * Fri Dec 30 2005 Dan Walsh 2.1.6-19 - Add Logwatch policy Broken deps for i386 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.i386 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.i386 requires libgcj.so.6 Broken deps for ia64 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.ia64 requires libgcj.so.6()(64bit) rgmanager - 1.9.31-3.ia64 requires ccs Broken deps for ppc ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc requires dlm-kernel-modules >= 0:2.6.11 gnbd - 1.0.1-2.ppc requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.ppc requires libgcj.so.6 Broken deps for ppc64 ---------------------------------------------------------- cman - 1.0.3-5.FC5.ppc64 requires cman-kernel-modules >= 0:2.6.11 dlm - 1.0.0-7.FC5.ppc64 requires dlm-kernel-modules >= 0:2.6.11 emacs - 21.4-5.ppc64 requires fonts-xorg-75dpi gnbd - 1.0.1-2.ppc64 requires gnbd-kernel-modules >= 0:2.6.11 jacorb - 2.2-3jpp_3fc.ppc64 requires libgcj.so.6()(64bit) Broken deps for s390 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.s390 requires libgcj.so.6 jonas - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 jonas-examples - 4.3.3-1jpp_15fc.s390 requires libgcj.so.6 systemtap - 0.5.2-2.s390 requires kernel >= 0:2.6.9-11 systemtap - 0.5.2-2.s390 requires kernel-devel Broken deps for s390x ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.s390x requires libgcj.so.6()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjava-2.8.so()(64bit) libvte-java - 0.11.11-7.s390x requires libgtkjni-2.8.so()(64bit) systemtap - 0.5.2-2.s390x requires kernel >= 0:2.6.9-11 systemtap - 0.5.2-2.s390x requires kernel-devel Broken deps for x86_64 ---------------------------------------------------------- jacorb - 2.2-3jpp_3fc.x86_64 requires libgcj.so.6()(64bit) jonas - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) jonas-examples - 4.3.3-1jpp_15fc.x86_64 requires libgcj.so.6()(64bit) From techie564 at gmail.com Sat Dec 31 08:54:27 2005 From: techie564 at gmail.com (Dave R) Date: Sat, 31 Dec 2005 09:54:27 +0100 Subject: lib problem KDE3.5.0 Message-ID: <8378d6f20512310054y117ffd91h8b5d859730b74c07@mail.gmail.com> I recently tried building packages of kde-3.5.0 on FC3, during compiling ran into error of non existent file for /lib/libattr.la and /lib/libacl.la to correct libattr.la I made a symlink in /lib. I didn't really like this method but seems to have worked I noticed for libacl-devel libacl.la has been removed by the spec file. If I removed the rm line would this cause any issues i've seen patches circulating for other distr. that add hook and syml to /lib for attr. >From the dist that I looked into /usr/lib seems to be the norm. correct me if I'm wrong but should this be addressed in KDE itself. Anyone care to shed some light on this would be greatly appreciated -- mobile_tux -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at miketc.com Sat Dec 31 09:14:05 2005 From: mike at miketc.com (Mike Chambers) Date: Sat, 31 Dec 2005 03:14:05 -0600 Subject: lastest boot.iso crashes during install - possible dmraid cause In-Reply-To: <43B6160E.6060902@interplas.com> References: <43B6160E.6060902@interplas.com> Message-ID: <1136020445.5098.1.camel@scrappy.miketc.com> On Sat, 2005-12-31 at 00:24 -0500, Eric Wood wrote: > Just wondering if this is happening to anyone else. > > I grabed the lastest boot.iso from: > > http://distro.ibiblio.org/pub/linux/distributions/fedora/linux/core/development/i386/images/boot.iso > > and it crashed right at the detection of the harddisks. I'm trying to > give some feedback to Peter Jones's call for dmraid testing: > https://www.redhat.com/archives/fedora-devel-list/2005-December/msg00474.html It's been crashing for the last few kernel builds, but supposively the .1805 build that comes out this morning (or already got built prior to writing this) should make rawhide bootable again. I'd say let the mirrors sync up then give it another try and see what happens. -- Mike Chambers Madisonville, KY "It's only funny until someone gets hurt, then it's hilarious!" From arjan at fenrus.demon.nl Sat Dec 31 09:15:16 2005 From: arjan at fenrus.demon.nl (Arjan van de Ven) Date: Sat, 31 Dec 2005 10:15:16 +0100 Subject: lib problem KDE3.5.0 In-Reply-To: <8378d6f20512310054y117ffd91h8b5d859730b74c07@mail.gmail.com> References: <8378d6f20512310054y117ffd91h8b5d859730b74c07@mail.gmail.com> Message-ID: <1136020516.2901.15.camel@laptopd505.fenrus.org> On Sat, 2005-12-31 at 09:54 +0100, Dave R wrote: > I recently tried building packages of kde-3.5.0 on FC3, during > compiling ran into error of non existent file for > /lib/libattr.la and /lib/libacl.la > > to correct libattr.la I made a symlink in /lib. I didn't really like > this method but seems to have worked > > I noticed for libacl-devel libacl.la has been removed by the spec > file. If I removed the rm line would this cause any issues it sounds really broken that you static link to this lib. Shared libraries are good. Shared libraries mean that if there's a security hole in one of them, you don't need to replace the entire distribution! (I still remember zlib from a few years ago ;-) esp something as extended attributes sounds like semi-security sensitive so I wonder why Fedora even ships the .a at all... From rdieter at math.unl.edu Sat Dec 31 10:54:32 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 31 Dec 2005 04:54:32 -0600 Subject: lib problem KDE3.5.0 In-Reply-To: <8378d6f20512310054y117ffd91h8b5d859730b74c07@mail.gmail.com> References: <8378d6f20512310054y117ffd91h8b5d859730b74c07@mail.gmail.com> Message-ID: Dave R wrote: > I recently tried building packages of kde-3.5.0 on FC3, during compiling > ran into error of non existent file for > /lib/libattr.la and /lib/libacl.la Long-standing packaging bug: https://bugzilla.redhat.com/bugzilla/171114 -- Rex From Axel.Thimm at ATrpms.net Sat Dec 31 15:20:25 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 31 Dec 2005 16:20:25 +0100 Subject: FC5 and Yum Plugins In-Reply-To: <43B5D549.3050103@redhat.com> References: <20051229193958.GC4833@neu.nirvana> <604aa7910512291149x75ca6dc9g22d6b7149943f2d5@mail.gmail.com> <6b9c17630512291901x4c16e064y5b3589db869f12c9@mail.gmail.com> <43B4A3C4.7080407@redhat.com> <20051230041904.GA22122@neu.nirvana> <43B4B8D3.2060608@redhat.com> <20051230044821.GA29376@neu.nirvana> <43B4BD54.8080600@redhat.com> <20051230121133.GB3297@neu.nirvana> <43B5D549.3050103@redhat.com> Message-ID: <20051231152025.GA10537@neu.nirvana> On Sat, Dec 31, 2005 at 06:18:09AM +0530, Rahul Sundaram wrote: > >>Getting bug reports based on packages being replaced isnt exactly a non > >>issue. > > > >Can you please point me to these bugs? > > > I dont have any handy now but ask anyone who hangs out in #fedora for > more than a week for the horror stories. Objection, your honor, hear-say. -- 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 Sat Dec 31 15:43:16 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 31 Dec 2005 16:43:16 +0100 Subject: FC5 and Yum Plugins In-Reply-To: <20051231152025.GA10537@neu.nirvana> References: <604aa7910512291149x75ca6dc9g22d6b7149943f2d5@mail.gmail.com> <6b9c17630512291901x4c16e064y5b3589db869f12c9@mail.gmail.com> <43B4A3C4.7080407@redhat.com> <20051230041904.GA22122@neu.nirvana> <43B4B8D3.2060608@redhat.com> <20051230044821.GA29376@neu.nirvana> <43B4BD54.8080600@redhat.com> <20051230121133.GB3297@neu.nirvana> <43B5D549.3050103@redhat.com> <20051231152025.GA10537@neu.nirvana> Message-ID: <20051231154316.GB23054@ryoko.camperquake.de> On Sat, Dec 31, 2005 at 04:20:25PM +0100, Axel Thimm wrote: > > I dont have any handy now but ask anyone who hangs out in #fedora for > > more than a week for the horror stories. > > Objection, your honor, hear-say. Well, you do not really make the case that replacing core packages with third party ones makes tracking down bugs for FC/FE any easier, do you? I think that if this extension is made part of core it should, by default, be on. Just because all sensible security measures should default to on. And I do consider protection against core package replacement a security measure. If people want that, they ought to have to make that active decision and have to flip the switch in order to do so. And, btw, this has nothing at all to do with the quality of the atrpms packages. From jeff.pitman at gmail.com Sat Dec 31 15:49:33 2005 From: jeff.pitman at gmail.com (Jeff Pitman) Date: Sat, 31 Dec 2005 23:49:33 +0800 Subject: FC5 and Yum Plugins In-Reply-To: <20051231154316.GB23054@ryoko.camperquake.de> References: <604aa7910512291149x75ca6dc9g22d6b7149943f2d5@mail.gmail.com> <43B4A3C4.7080407@redhat.com> <20051230041904.GA22122@neu.nirvana> <43B4B8D3.2060608@redhat.com> <20051230044821.GA29376@neu.nirvana> <43B4BD54.8080600@redhat.com> <20051230121133.GB3297@neu.nirvana> <43B5D549.3050103@redhat.com> <20051231152025.GA10537@neu.nirvana> <20051231154316.GB23054@ryoko.camperquake.de> Message-ID: <6b9c17630512310749q22ed56f7x781e911bac007b46@mail.gmail.com> On 12/31/05, Ralf Ertzinger wrote: > I think that if this extension is made part of core it should, by default, be > on. Just because all sensible security measures should default to on. And > I do consider protection against core package replacement a security measure. Well, then let's encrypt the filesystems while we're at it--for installs and upgrades. And no more pussy footin' around with SELinux in deactivated or audit mode; bring it on full force. -- -jeff From naheemzaffar at gmail.com Sat Dec 31 15:57:46 2005 From: naheemzaffar at gmail.com (Naheem Zaffar) Date: Sat, 31 Dec 2005 15:57:46 +0000 Subject: FC5 and Yum Plugins In-Reply-To: <20051231154316.GB23054@ryoko.camperquake.de> References: <604aa7910512291149x75ca6dc9g22d6b7149943f2d5@mail.gmail.com> <43B4A3C4.7080407@redhat.com> <20051230041904.GA22122@neu.nirvana> <43B4B8D3.2060608@redhat.com> <20051230044821.GA29376@neu.nirvana> <43B4BD54.8080600@redhat.com> <20051230121133.GB3297@neu.nirvana> <43B5D549.3050103@redhat.com> <20051231152025.GA10537@neu.nirvana> <20051231154316.GB23054@ryoko.camperquake.de> Message-ID: <3adc77210512310757p3115c13buf10b3a6198c95c8b@mail.gmail.com> Will this plugin allow packages to move from a protected core to a protected extras, and vice versa? After all That is a perfectly reasonable event. And a third question would be what if a 3rd party decides to move a package from 3rd party to extras? would this still work? And what if Core and Extras drop a package, which is picked up by a third party? will updated continue from 3rd party? I do not think it is useful to debate the politics (I am in favour of protecting official repo's by default. One should have to act to replace default packages...), unless this plugin is workable for fedora, or can be fixed to do so. Otherwise we are just blowing steam. -------------- next part -------------- An HTML attachment was scrubbed... URL: From fedora at camperquake.de Sat Dec 31 16:11:59 2005 From: fedora at camperquake.de (Ralf Ertzinger) Date: Sat, 31 Dec 2005 17:11:59 +0100 Subject: FC5 and Yum Plugins In-Reply-To: <6b9c17630512310749q22ed56f7x781e911bac007b46@mail.gmail.com> References: <43B4A3C4.7080407@redhat.com> <20051230041904.GA22122@neu.nirvana> <43B4B8D3.2060608@redhat.com> <20051230044821.GA29376@neu.nirvana> <43B4BD54.8080600@redhat.com> <20051230121133.GB3297@neu.nirvana> <43B5D549.3050103@redhat.com> <20051231152025.GA10537@neu.nirvana> <20051231154316.GB23054@ryoko.camperquake.de> <6b9c17630512310749q22ed56f7x781e911bac007b46@mail.gmail.com> Message-ID: <20051231161159.GC23054@ryoko.camperquake.de> On Sat, Dec 31, 2005 at 11:49:33PM +0800, Jeff Pitman wrote: > And no more pussy footin' around with SELinux > in deactivated or audit mode; bring it on full force. You do know that SELinux defaults to on unless you _manually_ turn it off during the installation? Now you do. From jspaleta at gmail.com Sat Dec 31 16:49:33 2005 From: jspaleta at gmail.com (Jeff Spaleta) Date: Sat, 31 Dec 2005 11:49:33 -0500 Subject: FC5 and Yum Plugins In-Reply-To: <3adc77210512310757p3115c13buf10b3a6198c95c8b@mail.gmail.com> References: <604aa7910512291149x75ca6dc9g22d6b7149943f2d5@mail.gmail.com> <20051230041904.GA22122@neu.nirvana> <43B4B8D3.2060608@redhat.com> <20051230044821.GA29376@neu.nirvana> <43B4BD54.8080600@redhat.com> <20051230121133.GB3297@neu.nirvana> <43B5D549.3050103@redhat.com> <20051231152025.GA10537@neu.nirvana> <20051231154316.GB23054@ryoko.camperquake.de> <3adc77210512310757p3115c13buf10b3a6198c95c8b@mail.gmail.com> Message-ID: <604aa7910512310849t4217a176ne884326b12ec0d15@mail.gmail.com> On 12/31/05, Naheem Zaffar wrote: > Will this plugin allow packages to move from a protected core to a protected > extras, and vice versa? > > After all That is a perfectly reasonable event. That's one of the problems with the concept of protectbase... for consistent operation across upgrades it would have to protect both Core and Extras if it were turned on by default.. preventing 3rd party repos from overriding even Extras. That's a very tight constraint on 3rd parties. This is an absolutely pointless default plugin. All it does is encourage people to selectively use 3rd party repositories in a way they were not designed or intended to be used. You either trust a repo or you don't. Repos that want to be strictly compatible with Core+Extras will choose to structure their offerings in a way that makes protectbase moot. Users who want atrpms to be strictly compatible with Core+Extras should go convince Axel to restructure. For 3rd parties who desire to offer replacement packages, atrpms, newrpms and livna ( in at least the case of audacity ) this plugin KILLS the intended purpose of the 3rd party repo and it WILL lead to untested and undiagnosable problems related to delibrately holding back replacement packages. 3rd parties have reasons for offering replacements. You either trust the reasoning of the 3rd party repo or you don't. If you do not want to trust the 3rd party repo.. do not use it for anything. I do not believe users who delibrately go out of their way to selectively pull crap from 3rd parties are worth "protecting". These users are delibrately doing things that the repository maintainers do not encourage nor recommend. This project should not make default settings that encourages users to abuse the intended purpose of 3rd party repos. The argument that this is a security measure.. is nuts. Once you choose to pull any packages from a 3rd party you sure as hell better trust the security practises of that 3rd party... scriplets can do amazingly wonderful things..even with selinux enabled. If you are concerned about the security implications from nrpms or atrpms or whatever.. you don't configure those repos for ANYTHING. The problem is NOT overlap.. the problem is users are googling for crackrock quick install instructions and finding "popular" instructions that shortcircuit repository usage patterns recommended by the repo maintainer. Do not doubt for a second that in the future "popular" recipe instructions will be created that tell users to turn this feature off so as to make something like nrpms work. I find it absolutely paradoxical that we are debating "protecting" users by default from 3rd party vendors they have to go out of their way to configure and enable to see on their system at all. Is there any usage other than mythtv right now, that invovles widespread selective use of a 3rd party repo? Widespread as in you can find a highly ranked google recipe that tells users to enable a repo selectively? All the mythtv users out there who want to selectively pull mythtv from atrpms., should convince Axel to jettison those packages off as a subrepo.. or stop using atrpms. Forcing a default configuration option that breaks how 3rd party repos are intended to work is the wrong solution. For users who want to use a repo selectively... yum already provides configuration directives to handle updating sanely. They are called exclude and includepkgs. Sadly the frelling recipe writers who are telling people how to add and use 3rd parties selectively are not telling people how to use the configuration directives to narrow the scope of the repo. man yum.conf. The original poster to this thread should take the time to learn how to configure his atrpm's definition to encode the mythtv packages selectively using "includepkgs" instead of looking to this project to create a hack default policy which supports his unrecommended package usage pattern. -jef From sundaram at redhat.com Sat Dec 31 17:03:41 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Sat, 31 Dec 2005 22:33:41 +0530 Subject: FC5 and Yum Plugins In-Reply-To: <20051231152025.GA10537@neu.nirvana> References: <20051229193958.GC4833@neu.nirvana> <604aa7910512291149x75ca6dc9g22d6b7149943f2d5@mail.gmail.com> <6b9c17630512291901x4c16e064y5b3589db869f12c9@mail.gmail.com> <43B4A3C4.7080407@redhat.com> <20051230041904.GA22122@neu.nirvana> <43B4B8D3.2060608@redhat.com> <20051230044821.GA29376@neu.nirvana> <43B4BD54.8080600@redhat.com> <20051230121133.GB3297@neu.nirvana> <43B5D549.3050103@redhat.com> <20051231152025.GA10537@neu.nirvana> Message-ID: <43B6B9ED.7050701@redhat.com> Axel Thimm wrote: >On Sat, Dec 31, 2005 at 06:18:09AM +0530, Rahul Sundaram wrote: > > >>>>Getting bug reports based on packages being replaced isnt exactly a non >>>>issue. >>>> >>>> >>>Can you please point me to these bugs? >>> >>> >>> >>I dont have any handy now but ask anyone who hangs out in #fedora for >>more than a week for the horror stories. >> >> > >Objection, your honor, hear-say. > > Not really. One of the people who hang around in #fedora is me. -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From dwmw2 at infradead.org Sat Dec 31 17:17:02 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 31 Dec 2005 17:17:02 +0000 Subject: FC5 and Yum Plugins In-Reply-To: <604aa7910512310849t4217a176ne884326b12ec0d15@mail.gmail.com> References: <604aa7910512291149x75ca6dc9g22d6b7149943f2d5@mail.gmail.com> <20051230041904.GA22122@neu.nirvana> <43B4B8D3.2060608@redhat.com> <20051230044821.GA29376@neu.nirvana> <43B4BD54.8080600@redhat.com> <20051230121133.GB3297@neu.nirvana> <43B5D549.3050103@redhat.com> <20051231152025.GA10537@neu.nirvana> <20051231154316.GB23054@ryoko.camperquake.de> <3adc77210512310757p3115c13buf10b3a6198c95c8b@mail.gmail.com> <604aa7910512310849t4217a176ne884326b12ec0d15@mail.gmail.com> Message-ID: <1136049422.3516.166.camel@pmac.infradead.org> On Sat, 2005-12-31 at 11:49 -0500, Jeff Spaleta wrote: > All the mythtv users out there who want to selectively pull mythtv > from atrpms., should convince Axel to jettison those packages off as a > subrepo.. or stop using atrpms. Er, or just volunteer to package mythtv for livna? -- dwmw2 From eric at interplas.com Sat Dec 31 17:51:09 2005 From: eric at interplas.com (Eric Wood) Date: Sat, 31 Dec 2005 12:51:09 -0500 Subject: Mirrors list needs to be livened up. Message-ID: <43B6C50D.4060307@interplas.com> I've wondered about this for years. I'v already emailed ftp+fedora at redhat.com about this idea. The mirrors list (http://fedora.redhat.com/Download/mirrors.html) could be livened up with some sortable stat columns (by country) showing: 1. Link Up/Down 2. Bandwidth 3. Mirrors the FC1,2,3,4,5... Development,etc. directories. 4. The Latest Dev Build Date/Has Lastest Updates 5. Days out of date for each of the sections. 6. Maybe even a torrent seed. People come and go and they typically *want* to use a mirror if they could just get a good recomendation of one. I'm just saying that the mirror pages could be made much more useful. -eric wood From eric at interplas.com Sat Dec 31 17:57:17 2005 From: eric at interplas.com (Eric Wood) Date: Sat, 31 Dec 2005 12:57:17 -0500 Subject: Mirrors list needs to be livened up. In-Reply-To: <43B6C50D.4060307@interplas.com> References: <43B6C50D.4060307@interplas.com> Message-ID: <43B6C67D.9050809@interplas.com> Maybe someone here can forward my idea over to the closed mailing list: mirror-list-d at fedora.us . 7. Is this a Tier 1 or Tier 2 mirror. -eric wood Eric Wood wrote: > I've wondered about this for years. I'v already emailed > ftp+fedora at redhat.com about this idea. > > The mirrors list (http://fedora.redhat.com/Download/mirrors.html) > could be livened up with some sortable stat columns (by country) showing: > 1. Link Up/Down > 2. Bandwidth > 3. Mirrors the FC1,2,3,4,5... Development,etc. directories. > 4. The Latest Dev Build Date/Has Lastest Updates > 5. Days out of date for each of the sections. > 6. Maybe even a torrent seed. > > People come and go and they typically *want* to use a mirror if they > could just get a good recomendation of one. I'm just saying that the > mirror pages could be made much more useful. > > -eric wood > From sundaram at redhat.com Sat Dec 31 17:58:50 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Sat, 31 Dec 2005 23:28:50 +0530 Subject: Mirrors list needs to be livened up. In-Reply-To: <43B6C50D.4060307@interplas.com> References: <43B6C50D.4060307@interplas.com> Message-ID: <43B6C6DA.5010801@redhat.com> Eric Wood wrote: > I've wondered about this for years. I'v already emailed > ftp+fedora at redhat.com about this idea. > > The mirrors list (http://fedora.redhat.com/Download/mirrors.html) > could be livened up with some sortable stat columns (by country) showing: > 1. Link Up/Down > 2. Bandwidth > 3. Mirrors the FC1,2,3,4,5... Development,etc. directories. > 4. The Latest Dev Build Date/Has Lastest Updates > 5. Days out of date for each of the sections. > 6. Maybe even a torrent seed. > > People come and go and they typically *want* to use a mirror if they > could just get a good recomendation of one. I'm just saying that the > mirror pages could be made much more useful. > > -eric wood See http://fedoraproject.org/wiki/Infrastructure/MirrorManagement. Your ideas could probably add value to that. -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From eric at interplas.com Sat Dec 31 18:09:25 2005 From: eric at interplas.com (Eric Wood) Date: Sat, 31 Dec 2005 13:09:25 -0500 Subject: Mirrors list needs to be livened up. In-Reply-To: <43B6C6DA.5010801@redhat.com> References: <43B6C50D.4060307@interplas.com> <43B6C6DA.5010801@redhat.com> Message-ID: <43B6C955.5090805@interplas.com> Rahul Sundaram wrote: > See http://fedoraproject.org/wiki/Infrastructure/MirrorManagement. > Your ideas could probably add value to that. > Thanks, I knew I wasn't the only one wondering this. However, I thought a simple php script with some easy directory parsings would liven up the mirror page in a hurry - I guess a full fledged project management team is needed. ~~ -eric wood From Axel.Thimm at ATrpms.net Sat Dec 31 18:31:47 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 31 Dec 2005 19:31:47 +0100 Subject: FC5 and Yum Plugins In-Reply-To: <1136049422.3516.166.camel@pmac.infradead.org> References: <43B4B8D3.2060608@redhat.com> <20051230044821.GA29376@neu.nirvana> <43B4BD54.8080600@redhat.com> <20051230121133.GB3297@neu.nirvana> <43B5D549.3050103@redhat.com> <20051231152025.GA10537@neu.nirvana> <20051231154316.GB23054@ryoko.camperquake.de> <3adc77210512310757p3115c13buf10b3a6198c95c8b@mail.gmail.com> <604aa7910512310849t4217a176ne884326b12ec0d15@mail.gmail.com> <1136049422.3516.166.camel@pmac.infradead.org> Message-ID: <20051231183147.GA15058@neu.nirvana> On Sat, Dec 31, 2005 at 05:17:02PM +0000, David Woodhouse wrote: > On Sat, 2005-12-31 at 11:49 -0500, Jeff Spaleta wrote: > Er, or just volunteer to package mythtv for livna? That is the second time this suggestion comes up in this thread. What makes livna and ATrpms different, or say livna preferable to ATrpms in this context? At the beginning of this thread some people posted about livna replacing packages just as well. Just for the note: Fedora itself, when it wasn't merged with RHL (aka fedora.us) decided to have vendor packages replaced. packages like shadow-utils or rpm itself. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Dec 31 18:41:30 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 31 Dec 2005 19:41:30 +0100 Subject: FC5 and Yum Plugins In-Reply-To: <43B6B9ED.7050701@redhat.com> References: <6b9c17630512291901x4c16e064y5b3589db869f12c9@mail.gmail.com> <43B4A3C4.7080407@redhat.com> <20051230041904.GA22122@neu.nirvana> <43B4B8D3.2060608@redhat.com> <20051230044821.GA29376@neu.nirvana> <43B4BD54.8080600@redhat.com> <20051230121133.GB3297@neu.nirvana> <43B5D549.3050103@redhat.com> <20051231152025.GA10537@neu.nirvana> <43B6B9ED.7050701@redhat.com> Message-ID: <20051231184130.GB15058@neu.nirvana> On Sat, Dec 31, 2005 at 10:33:41PM +0530, Rahul Sundaram wrote: > Axel Thimm wrote: > >On Sat, Dec 31, 2005 at 06:18:09AM +0530, Rahul Sundaram wrote: > >>>>Getting bug reports based on packages being replaced isnt exactly a non > >>>>issue. > >>>Can you please point me to these bugs? > >>I dont have any handy now but ask anyone who hangs out in #fedora for > >>more than a week for the horror stories. > >Objection, your honor, hear-say. > Not really. One of the people who hang around in #fedora is me. So you should be able to mention a couple real life issues/bugzillas. If it ain't in bugzilla, it ain't a bug, right? No, seriously. I guess you are a victim of this FUD just like many other people, too. There really isn't any correlation between a package being replaced/updated and having more bugs for this packages. On the contrary I would even assert, that for ATrpms the contrary is true: packages being replaced have a higher maturity, as they have either been taken out of ATrpms into FC, or ATrpms has enhanced the build with more BuildRequires/configure options. Packages required at a newer version are usually checked against Rawhide. -- 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 redhat.com Sat Dec 31 18:47:55 2005 From: sundaram at redhat.com (Rahul Sundaram) Date: Sun, 01 Jan 2006 00:17:55 +0530 Subject: FC5 and Yum Plugins In-Reply-To: <20051231184130.GB15058@neu.nirvana> References: <6b9c17630512291901x4c16e064y5b3589db869f12c9@mail.gmail.com> <43B4A3C4.7080407@redhat.com> <20051230041904.GA22122@neu.nirvana> <43B4B8D3.2060608@redhat.com> <20051230044821.GA29376@neu.nirvana> <43B4BD54.8080600@redhat.com> <20051230121133.GB3297@neu.nirvana> <43B5D549.3050103@redhat.com> <20051231152025.GA10537@neu.nirvana> <43B6B9ED.7050701@redhat.com> <20051231184130.GB15058@neu.nirvana> Message-ID: <43B6D25B.1000706@redhat.com> Hi >So you should be able to mention a couple real life >issues/bugzillas. If it ain't in bugzilla, it ain't a bug, right? > > Thats what you tell people. If their system gets messed up to the point that getting them to file bug reports is useless or if they complain about how bad bugzilla is in return you tend to give up after a while. >No, seriously. I guess you are a victim of this FUD just like many >other people, too. There really isn't any correlation between a >package being replaced/updated and having more bugs for this packages. > > I didnt claim that you get more bugs. Just that you get irrelevant ones. -- Rahul Learn. Network. Experience open source. Red Hat Summit Nashville | May 30 - June 2, 2006 Learn more: http://www.redhat.com/promo/summit/ From Axel.Thimm at ATrpms.net Sat Dec 31 19:02:21 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 31 Dec 2005 20:02:21 +0100 Subject: FC5 and Yum Plugins In-Reply-To: <20051231154316.GB23054@ryoko.camperquake.de> References: <6b9c17630512291901x4c16e064y5b3589db869f12c9@mail.gmail.com> <43B4A3C4.7080407@redhat.com> <20051230041904.GA22122@neu.nirvana> <43B4B8D3.2060608@redhat.com> <20051230044821.GA29376@neu.nirvana> <43B4BD54.8080600@redhat.com> <20051230121133.GB3297@neu.nirvana> <43B5D549.3050103@redhat.com> <20051231152025.GA10537@neu.nirvana> <20051231154316.GB23054@ryoko.camperquake.de> Message-ID: <20051231190221.GC15058@neu.nirvana> On Sat, Dec 31, 2005 at 04:43:16PM +0100, Ralf Ertzinger wrote: > On Sat, Dec 31, 2005 at 04:20:25PM +0100, Axel Thimm wrote: > > > > I dont have any handy now but ask anyone who hangs out in #fedora for > > > more than a week for the horror stories. > > > > Objection, your honor, hear-say. > > Well, you do not really make the case that replacing core packages with third > party ones makes tracking down bugs for FC/FE any easier, do you? Please show first that there is a case here at all. The discussion is the same for three years now, and it is still an academic one. Plase find some reported bugs in the hundred thousand bugzillas there that was really hindered by third party packaging at ATrpms. > I think that if this extension is made part of core it should, by default, be > on. Just because all sensible security measures should default to on. And > I do consider protection against core package replacement a security measure. You're my man! I really waited for this argument to come. So what about non-replacing kernel module packages? And new daemons that selinux doesn't even know about? Packages ripping open your ports to the world w/o having to replace any single package? It is very true, if you are a security paranoid, you should avoid replacement packages, but you should avoid the rest, too. And if you are concerned with system stability, first thing you should ban are packages introducing new kernel modules. Funny that noone cares about that. So security and stability are obviously not the main argument for soem people advising against some repos. I'll remain on the standpoint that there are still politics going on, and if the repos in question like ATrpms, kde-redhat etc would succumb to a pinful split of their repos or introduce any other time comsuming effort to shut down these arguments new ones will pop up. As a forecast: o Don't use third party repos due to repository mixing problems (-> argument three years ago, now show to be a neglidible problem ...) o don't use repo that replace packages (current pet argument for repository mobbing) o Third party repositories don't have enough security in place to be trusted (future argument) o The point I want to make is: There was a differing of opinions some years back known to the elder users here. I was hoping that this had come to rest and we would get forward, but there is still a core that tries to sabotage 3rd party repos (not explicitly anyone on this thread!) by spreading FUD and mischief about 3rd party repos. Any distinguishing mark found that could be attacked will be, trust me. Just to make it clear: If anyone wants to invest his/her time in getting a better ATrpms should go ahead and do so. Same for any other attacked repo. That's the way OSS works, right? Maybe he or she will come back with a changed point of view, or even better find a better way to please them all. > If people want that, they ought to have to make that active decision > and have to flip the switch in order to do so. They do by configuring their depsolver to trust that repo in any way, either by replacement packages, new daemons, new kernel modules and for not shipping Trojan rpms. > And, btw, this has nothing at all to do with the quality of the > atrpms packages. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From tdiehl at rogueind.com Sat Dec 31 19:09:50 2005 From: tdiehl at rogueind.com (Tom Diehl) Date: Sat, 31 Dec 2005 14:09:50 -0500 (EST) Subject: FC5 and Yum Plugins In-Reply-To: <20051231183147.GA15058@neu.nirvana> References: <43B4B8D3.2060608@redhat.com> <20051230044821.GA29376@neu.nirvana> <43B4BD54.8080600@redhat.com> <20051230121133.GB3297@neu.nirvana> <43B5D549.3050103@redhat.com> <20051231152025.GA10537@neu.nirvana> <20051231154316.GB23054@ryoko.camperquake.de> <3adc77210512310757p3115c13buf10b3a6198c95c8b@mail.gmail.com> <604aa7910512310849t4217a176ne884326b12ec0d15@mail.gmail.com> <1136049422.3516.166.camel@pmac.infradead.org> <20051231183147.GA15058@neu.nirvana> Message-ID: Axel Thimm wrote: > On Sat, Dec 31, 2005 at 05:17:02PM +0000, David Woodhouse wrote: >> On Sat, 2005-12-31 at 11:49 -0500, Jeff Spaleta wrote: >> Er, or just volunteer to package mythtv for livna? > >That is the second time this suggestion comes up in this thread. What >makes livna and ATrpms different, or say livna preferable to ATrpms in >this context? At the beginning of this thread some people posted about >livna replacing packages just as well. The fact that Livna would not pull in a bunch of rpms that, for instance myth TV does not need. The last time I tried to install a myth box from ATrpms it wanted to replace yum. NO, I do not want the ATrpm version of yum installed. Myth does not need it. I only want the packages NECESSARY for myth to work installed. IIRC, I thought I could bump my version of yum to override it but upon inspection there was some specific tag that required the use of the ATrpms version. In addition I seem to remember the dep-solver pulling in some other equally unnecessary packages but I cannot remember which ones. I use a custom version of yum that I build so that I can serve up the yum.conf files from a web server. Why would I want to replace my version of yum with ATrpms? If ATrpm's deps were sane this would not be a problem but the last time I looked they are not. >Just for the note: Fedora itself, when it wasn't merged with RHL (aka >fedora.us) decided to have vendor packages replaced. packages like >shadow-utils or rpm itself. IIRC only on a VERY limited basis. If you are referring to the rpm upgrade for RHL 8.0, as far as I am concerned NOT upgrading was a mistake on Red Hat's part. That upgrade made the system usable and the decision to do that was very controversial. Disclaimer: I have not actually looked at this in approx 6 months. If things have changed then that is good and I would appreciate being corrected. I really do appreciate the work 3rd party repos do. I used to use Dag's repo quite frequently and I would gladly use ATrpms if the deps were not so intrusive. Regards, Tom Diehl tdiehl at rogueind.com Spamtrap address mtd123 at rogueind.com From Axel.Thimm at ATrpms.net Sat Dec 31 19:20:38 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 31 Dec 2005 20:20:38 +0100 Subject: FC5 and Yum Plugins In-Reply-To: <43B6D25B.1000706@redhat.com> References: <20051230041904.GA22122@neu.nirvana> <43B4B8D3.2060608@redhat.com> <20051230044821.GA29376@neu.nirvana> <43B4BD54.8080600@redhat.com> <20051230121133.GB3297@neu.nirvana> <43B5D549.3050103@redhat.com> <20051231152025.GA10537@neu.nirvana> <43B6B9ED.7050701@redhat.com> <20051231184130.GB15058@neu.nirvana> <43B6D25B.1000706@redhat.com> Message-ID: <20051231192038.GD15058@neu.nirvana> On Sun, Jan 01, 2006 at 12:17:55AM +0530, Rahul Sundaram wrote: > Hi > > >So you should be able to mention a couple real life > >issues/bugzillas. If it ain't in bugzilla, it ain't a bug, right? > > > > > Thats what you tell people. If their system gets messed up to the point > that getting them to file bug reports is useless or if they complain > about how bad bugzilla is in return you tend to give up after a while. > > >No, seriously. I guess you are a victim of this FUD just like many > >other people, too. There really isn't any correlation between a > >package being replaced/updated and having more bugs for this packages. > > > > > I didnt claim that you get more bugs. Just that you get irrelevant ones. I'm only asking for real-life examples, not hypothetical ones. Given the bad hear-say and FUD on ATrpms one assumes that there would be a ton of them, so where is it? -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Dec 31 19:34:32 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 31 Dec 2005 20:34:32 +0100 Subject: FC5 and Yum Plugins In-Reply-To: References: <43B4BD54.8080600@redhat.com> <20051230121133.GB3297@neu.nirvana> <43B5D549.3050103@redhat.com> <20051231152025.GA10537@neu.nirvana> <20051231154316.GB23054@ryoko.camperquake.de> <3adc77210512310757p3115c13buf10b3a6198c95c8b@mail.gmail.com> <604aa7910512310849t4217a176ne884326b12ec0d15@mail.gmail.com> <1136049422.3516.166.camel@pmac.infradead.org> <20051231183147.GA15058@neu.nirvana> Message-ID: <20051231193432.GE15058@neu.nirvana> On Sat, Dec 31, 2005 at 02:09:50PM -0500, Tom Diehl wrote: > Axel Thimm wrote: > > > On Sat, Dec 31, 2005 at 05:17:02PM +0000, David Woodhouse wrote: > >> On Sat, 2005-12-31 at 11:49 -0500, Jeff Spaleta wrote: > >> Er, or just volunteer to package mythtv for livna? > > > >That is the second time this suggestion comes up in this thread. What > >makes livna and ATrpms different, or say livna preferable to ATrpms in > >this context? At the beginning of this thread some people posted about > >livna replacing packages just as well. > > The fact that Livna would not pull in a bunch of rpms that, for instance myth TV > does not need. The last time I tried to install a myth box from ATrpms > it wanted to replace yum. NO, I do not want the ATrpm version of yum installed. > Myth does not need it. Oh yes, it did: https://www.redhat.com/archives/fedora-list/2005-January/msg01826.html Maybe it doesn't anymore, but for good manners everytime a yum release comes up and mentiones bugs fixed I run and distribute it to ATrpms folks and they are *happy* about it. Especially the ones running FC older then the latest, that doesn't get any yum problems fixed anymore. > I only want the packages NECESSARY for myth to work installed. IIRC, > I thought I could bump my version of yum to override it but upon > inspection there was some specific tag that required the use of the > ATrpms version. No, that's wrong. yum/smart/apt at ATrpms are deliberately kept atrpms agnostic, so they can be used in any other context. You can even use them w/o using ATrpms at all. > I use a custom version of yum that I build so that I can serve up the yum.conf > files from a web server. Why would I want to replace my version of yum with > ATrpms? If ATrpm's deps were sane this would not be a problem but the last time > I looked they are not. The problme is that you want a piece of the cake and not all of it. You could just as well not like firefox version so and so shipped with Fedora Core. Using Fedora Core means that there is an ensemble of packages that you pull from. Using a third party repository is no different. Noone needs all of ATrpms. Noone needs all of Fedora Core either. But it is not easy to create a subrepo for every taste. Some like it mythtv, others like cluster software, others security scan tools. If a 3rd party repo were to fine grain its contents it would probably end up with a suprepo per package. I once was trying to keep packages in "topics", but soon failed to properly continue it due to the overhead induced: http://atrpms.net/topic/ It really gets a nightmare to serve sub-repos. > >Just for the note: Fedora itself, when it wasn't merged with RHL (aka > >fedora.us) decided to have vendor packages replaced. packages like > >shadow-utils or rpm itself. > > IIRC only on a VERY limited basis. If you are referring to the rpm upgrade > for RHL 8.0, as far as I am concerned NOT upgrading was a mistake on Red Hat's > part. That upgrade made the system usable and the decision to do that was > very controversial. I don't want to go into detail, I myself applaude this decision, I just want to demostrate that this was once a policy of Fedora and then suddenly became a sin for 3rd party repos. Doesn't that make you feel like a second class citizen? > Disclaimer: I have not actually looked at this in approx 6 months. If things > have changed then that is good and I would appreciate being corrected. I really > do appreciate the work 3rd party repos do. I used to use Dag's repo quite > frequently and I would gladly use ATrpms if the deps were not so intrusive. That explains the above statements. W/o wanting to push you, you are making claims that aren't true neither now nor back then, because you either forgot the details or only checked superficially the problems you were facing. So you're actually adding to the problem of FUD. -- Axel.Thimm at ATrpms.net -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: not available URL: From Axel.Thimm at ATrpms.net Sat Dec 31 19:50:43 2005 From: Axel.Thimm at ATrpms.net (Axel Thimm) Date: Sat, 31 Dec 2005 20:50:43 +0100 Subject: ATrpms and FC5/RHEL5 Message-ID: <20051231195043.GF15058@neu.nirvana> So, is there interest to have ATrpms for FC5 less overlapping with core packages? If so, is there any redhat.com folk that would be willing to add versioned obsoletes/provides to core specfiles? That's neccessary to ensure upgradability. -- 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 dwmw2 at infradead.org Sat Dec 31 19:59:25 2005 From: dwmw2 at infradead.org (David Woodhouse) Date: Sat, 31 Dec 2005 19:59:25 +0000 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <20051231195043.GF15058@neu.nirvana> References: <20051231195043.GF15058@neu.nirvana> Message-ID: <1136059165.3516.173.camel@pmac.infradead.org> On Sat, 2005-12-31 at 20:50 +0100, Axel Thimm wrote: > If so, is there any redhat.com folk that would be willing to add > versioned obsoletes/provides to core specfiles? That's neccessary to > ensure upgradability. Can you show specific examples of where this is required? In bugzilla, perhaps? -- dwmw2 From rdieter at math.unl.edu Sat Dec 31 20:58:56 2005 From: rdieter at math.unl.edu (Rex Dieter) Date: Sat, 31 Dec 2005 14:58:56 -0600 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <20051231195043.GF15058@neu.nirvana> References: <20051231195043.GF15058@neu.nirvana> Message-ID: <43B6F110.1010808@math.unl.edu> Axel Thimm wrote: > If so, is there any redhat.com folk that would be willing to add > versioned obsoletes/provides to core specfiles? That's neccessary to > ensure upgradability. They (redhat folk) have been receptive to Versioning previously non-versioned Obsoletes/Provides in the past when I've requested it on several occasions. However, if you're asking in the context "will they add these simply to be compatible/upgradable with ATrpms", then I bet the proposition will be less well-received. -- Rex From ellson at research.att.com Sat Dec 31 22:56:00 2005 From: ellson at research.att.com (John Ellson) Date: Sat, 31 Dec 2005 17:56:00 -0500 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <43B6F110.1010808@math.unl.edu> References: <20051231195043.GF15058@neu.nirvana> <43B6F110.1010808@math.unl.edu> Message-ID: <43B70C80.1030701@research.att.com> Rex Dieter wrote: > Axel Thimm wrote: > >> If so, is there any redhat.com folk that would be willing to add >> versioned obsoletes/provides to core specfiles? That's neccessary to >> ensure upgradability. > > They (redhat folk) have been receptive to Versioning previously > non-versioned Obsoletes/Provides in the past when I've requested it on > several occasions. > > However, if you're asking in the context "will they add these simply > to be compatible/upgradable with ATrpms", then I bet the proposition > will be less well-received. > > -- Rex > Please don't make this into a political thing. Axel provides a great service to the Redhat/Fedora user community. Lets have a discussion about the technicalities, and just do it. Can I assume we're looking for solutions that also help DAG, Dries, Livna ? John From ellson at research.att.com Sat Dec 31 23:08:02 2005 From: ellson at research.att.com (John Ellson) Date: Sat, 31 Dec 2005 18:08:02 -0500 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <20051231195043.GF15058@neu.nirvana> References: <20051231195043.GF15058@neu.nirvana> Message-ID: <43B70F52.6090406@research.att.com> Axel Thimm wrote: > So, is there interest to have ATrpms for FC5 less overlapping with > core packages? > Less overlap is probably a good thing. It should at least free up some of your resources for non-overlapping packages. However, I doubt that overlaps can be completely eliminated, or that it is even desirable to completely eliminate them, so I think it is more important to have a clear mechanism to allow the user to control the default choice, and to be able to override it if desired. > If so, is there any redhat.com folk that would be willing to add > versioned obsoletes/provides to core specfiles? That's neccessary to > ensure upgradability. > Hopefully, but what can we do to minimize their effort? John From cmadams at hiwaay.net Sat Dec 31 23:37:59 2005 From: cmadams at hiwaay.net (Chris Adams) Date: Sat, 31 Dec 2005 17:37:59 -0600 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <43B70F52.6090406@research.att.com> References: <20051231195043.GF15058@neu.nirvana> <43B70F52.6090406@research.att.com> Message-ID: <20051231233759.GD1197025@hiwaay.net> Once upon a time, John Ellson said: > However, I doubt that overlaps can be completely eliminated, or that > it is even desirable to completely eliminate them, so I think it is > more important to have a clear mechanism to allow the user to control > the default choice, and to be able to override it if desired. The best thing would be for the third-party repos to be split into overlapping and non-overlapping. Anything that doesn't replace a Core or Extras package (or require such a package) could go in a non-overlapping repo and things that does could go in an "alternatives" repo. That would leave the choice in the hands of the users; if they just want to add some compatible software to their Fedora system, they can just use a third-party base non-overlapping repo. If they want to replace Core and/or Extras packages with enhanced/updated/etc. packages from a third part repo, they use that third-party's alternatives repo. That still requires some end-user "buy-in"; I might want just one alternative from a third-party without wanting others, but I don't see it being practical to make it any finer grained. -- Chris Adams Systems and Network Administrator - HiWAAY Internet Services I don't speak for anybody but myself - that's enough trouble. From florin at andrei.myip.org Sat Dec 31 22:12:55 2005 From: florin at andrei.myip.org (Florin Andrei) Date: Sat, 31 Dec 2005 14:12:55 -0800 Subject: ATrpms and FC5/RHEL5 In-Reply-To: <20051231195043.GF15058@neu.nirvana> References: <20051231195043.GF15058@neu.nirvana> Message-ID: <1136067175.3755.53.camel@rivendell.home.local> On Sat, 2005-12-31 at 20:50 +0100, Axel Thimm wrote: > So, is there interest to have ATrpms for FC5 less overlapping with > core packages? ATrpms is a great repository, but my perpetual pet peeve is that it replaces and messes with way too many packages in the distribution. If that's the overlapping that you refer to, I'd be glad to see it reduced. I very much prefer the model of Extras and Livna, which don't replace anything, just add things. -- Florin Andrei http://florin.myip.org/